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This book is a product of a research project that tackled one of the key 
challenges currently facing the software industry in Europe, and indeed 
worldwide, namely, how do we transform our organization as software increas- 
ingly becomes a critical part of our business? How can we support the digitali- 
zation of assets and offerings? 


This book presents the Scaling Management Framework (SMF), which is unique in 
the sense that it supports the above transformation in three domains: 1) products 
systems & services, 2) organization & business, and 3) methods & processes. These 
domains are interdependent and are integrated into a single model in the SMF. 


ITEAZ 


INFORMATION TECHNOLOGY FOR EUROPEAN ADVANCEMENT 


The framework was developed in the SCALARE (“SCAling softwARE”) proj- 
ect which was а pan-European project funded under the auspices of the ITEA 
(Information Technology for European Advancement), a program in the EU- 
REKA Cluster program that supports industry-driven research in the area of 
software-intensive systems & services. 


The intensive case-study approach adopted throughout the project makes the 
framework highly relevant for today’s businesses. The project members have 
drawn on over 300 years of software engineering and senior management 
experience conducting more than 30 company case studies companies in 
Germany, Ireland, Spain and Sweden. 


The project was supported by Enterprise Ireland, Science Foundation 
Ireland, and the Swedish innovation agency, Vinnova. 
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== where innovation means business Ireland For what's next 


The digitalization transformation in both industry and society has been ongoing for several 
decades. Companies in the telecom industry were early movers, whereas the automotive industry 
is currently in the midst of their digitalization journey. Digitalization implies a shift in focus from 
hardware and products towards software and services and possibly disruptive business models. 
This is a game-changer for most companies and the race is on right now. 


You may be in a situation where you want to take the next step to increase your usage of soft- 
ware and services in your offerings. You need to do something, but you don't know what options 
you have, nor what actions you need to take. 


$» SCALARE 


The SCALARE project? draws on the Scal- 
ing Management Framework (SMF) to provide 
guidance on creating a roadmap for different 
scaling approaches such as Open Source, Lean 
& Agile and global software development. 


Ж http://www.scalare.org 


The answer to the question of “how to make a roadmap of our transformation?" can be found in 
knowledge gleaned from previous experiences, and the SMF provides an easy way to find information 
that is relevant to you. The framework helps you to understand your own situation. It will help pin 
down what you want to achieve and how to use this knowledge to search for valid solutions. It also рго- 
vides guidance to help include all personnel in the process, to use their knowledge about the company. 


The SCALARE team's objectives 


There are many models that can be used to analyze and assess companies and their 
products. Often they have a grading system to evaluate whether they are good or bad. 
However, they are often also quite specialized for specific business domains. 


Considering the increasing importance of software throughout the entire company, the 
model must covet all perspectives of a software business, not just the technical aspects. 


This resulted in the integration of the three domains, 
product, process, and organization into a single model. 
The SCALARE team found it very difficult, and indeed misguided, to argue there was 
only one way to accomplish the transformation. Presenting a smorgasbord of possi- 
ble ways to improve, there would inevitably be arguments for different and additional 
practices. Instead, the SMF became a mechanism to design a structure where relevant 
real experiences could be added. 


The model does not produce an evaluation grade for activities, 
but can be used to capture and describe many different situations. 


Even though this reduced the model itself and made it simpler, it was still what we 
desired and needed. 
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We're in a business where most of our product features have to be realized with software. Adding 
software to a business is a complex enterprise, whether we start from scratch or take our products 
to the next level. There are as many ways to organize such product evolutions as there are people 
involved. Howevet, reality leaves us no choice: we have to take the plunge in order to sustain our 
business. Fortunately, many companies have already embarked on such journeys. Based on numer- 
ous case studies with a variety of companies in different domains, we developed the Scaling Man- 
agement Framework (SMF). The SMF codifies past experiences and offers systematic guidance to 
assess our starting point as well as our destination. This book is full of stories of companies, and 
we describe their journeys using the SMF. Ericsson is one such company, and we start telling their 
story next. 


How a dozen software developers became several thousands in 
a few years - the story of a technical and an organizational boom 


Hello world 


The big breakthrough for mobile telephony during the nineties is a part of tech- 
nological history characterized by intense competition between innovative com- 
panies. For Ericsson Mobile Communications, it meant a period of explosive 
expansion of the mobile phone software development department in Lund, 
Sweden: growing from a handful of developets, to an army of thousands within 
a few years. While this story is from the days when mobile telephony was made 
into an everyday tool for billions of people, it's still highly relevant for all of us 
interested in scaling a business. 


The software organization in Ericsson's mobile phones is a great example of an 
otganization that just keeps growing and growing. It started in 1992 when Erics- 
son introduced their first GSM phone. At that time, only a dozen people worked 
on the software for mobile phones. Eleven of them were working with the 
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technical and telecoms-related platform software. Only one of the developers was responsi- 
ble for the phones' user interface. You could use the phone to make calls — but that's about 
all you could do. 


Just five years later, the mobile phone world looked very different. Second generation (2G) 
GSM offered more powerful services, and operators offered better terms and prices, which 
led to an increase in mobile phone users. In the latter half of the nineties, email and internet 
services were no longer exclusively used by academics and companies, but were now available 
and affordable to the wider public. As technology advanced, customers had growing expec- 
tations to have advanced features on all their devices. 


Programmers were thrown into As customers were demanding an increasing level of 
the project, only to drown in the “mobility” and the ability to access a fast growing num- 
complexity of maintaining exist- ber of network services, Ericsson Mobile Communi- 
ing functionality while developing cations R&D department faced major challenges. The 
new features number of different phone models. The amount of 
software in phones grew exponentially and doubled 
every 18 months — closely aligned with Moore's Law. Programmets were thrown into the 
project, only to drown in the complexity of maintaining existing functionality while devel- 


oping new features. Teams were no longer co-located but were distributed over different 
sites. Every month, the technical complexity increased: more different phone models, 
more network services, more feature requests from customers, and more innovations 
from competitors. Mobile phone operators demanded a continuous stream of soft- 
ware updates to the phones they were selling and had no intention of waiting. In y^. 
2000, Ericsson launched the R380, the first "smartphone." At this time, Erics- : 
son had some 40 different phone models, and countless combinations of Г ) 
hardware, software, and infrastructure services. е 


It was time to take the plunge. As the software grew exponentially, the change process had 
to embrace the entire organization. Product and system architecture, organizational changes, 
business and development processes — all had to adapt in a coordinated manner towards a 
common goal. Rules for what can and cannot be done with the software had to be estab- 
lished. The organization needed to think in new ways, to invest in a software architecture that 
was designed to scale. It became crucial to introduce stringent configuration management to 
control the wide variety of different software versions. 


Being well into the 2010s, the ongoing digitalization of industry and 
public organizations leaves few companies untouched. To survive, many 
have to change. Fortunately, there is much to learn from stories like 


Ericssons. With this book, we want to share their and others experiences 
with you. At the end of the day, you will hopefully have an idea of how to 
transform your business, successfully. 
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“Out organization has become a software company. The problem is that we haven't realized that 


pP? 


yet!" This is how the VP of a major semiconductor manufacturing company, traditionally seen as 
a classic hardware company, characterized the context in which software solutions were replacing 
hardware in their products. This organization knew precisely the threshold of reuse level for their 
hardware components before “designing for reuse" became cost-effective. However, no such so- 


phistication was present in their software processes. 


The digitalization of society is changing businesses more rapidly than ever seen before, there are 
countless other scenarios emerging. It is difficult to find a market domain in which the innovation 
does not depend on software. 


For several years now, we have seen how traditional compa- 
nies adopt novel and clever business concepts using digital 


Our organization has 


technologies that integrate into our everyday life. Everything 


become a software that can be digitalized 1s digitalized, and 
company. any data that can be collected is 

The problem is that collected. 

we haven't realized Technological advances, such as 

that yet! the emergence of cloud-based 


solutions, mobile devices and 


сот 
social media have paved the Rr 
way Юг this evolution. Take smart watches, for example, which are Sa | | 
becoming very popular. By adding software to an ordinary watch, у 


it can now access internet services which opens up a wide range of 
new possibilities and opportunities. The Smart watch is an excel- 
lent example of products that have emerged from digitalization. 


What motivates these companies to transform their businesses, 
what ate their goals, or to put it differently, what ate the business 
drivers? The primary answer is that software affords development 
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of new business opportunities. Some companies see radical cost savings from digitalization, 
where others see revenue growth by creating innovative products and services. So, it's not sur- 
prising that traditional industries such as manufacturing are now in the midst of developing their 
digital strategies. Software has become a critical part of their product offerings, but they need 

to scale the business systematically in order to not lose momentum, or wotse, to lose business 
altogether. 


How do they do it? Needless to say, transforming software requires rethinking existing processes 
as well as incorporating new practices and tools. Studying other companies to see how they ap- 
proached the transformation is a very useful exercise as it teaches us so many things. All of them 
have mote ot less created a new sort of IT organization. In the digitalized company, IT is not 
only about internal network services and technology, but also deals with business models and the 
digital platform for customer facing services and products. It's not unlikely that the traditional IT 
otganizations dissolve and merge with development organizations as a consequence. 


Obviously, IT is just one of the cogwheels in the digitalized business that need to spin in new 
ways. The entire organization will need a lift. As this chapter proceeds, it will become clear that it 
all boils down to a company's motivations to transform: the business drivers. 


This is the point of departure for this book. The transformation journey can be done in a variety 
of ways, but ultimately we can categorize any software transforming activity to one of three 
domains product, process, or organization. 


Knowing what needs to be done is quintessential when approaching the digital transformation. 


This book offers a method that will help your organization in three ways: 


2 3 


The map. The SMF canvas is The compass. Five groups The journeys. An experience 
the map of the digital trans- of common drivers that will database with best practices 
formation. It helps you in cre- help you to find your digital and lessons learned from past 
ating a digitalization strategy. transformation journey. digitalization transformations. 


This book embodies three years of research that was conducted in a European project called 
“SCAling softwARE” — SCALARE for short — which was established by a consortium of partners 
in Germany, Ireland, Spain, and Sweden. 


Over 30 case studies were conducted, involving companies in a variety of domains, ranging from 
pharma to automotive as well as emerging industries that aim to deliver IoT (Internet of Things) 
products and setvices.. Each case study is based on in-depth interviews with vice presidents, direc- 
tors, managets, supervisors and front-line service employees. 
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Let's get back to the starting point of this book: why do companies need to transform? Answering 
this question will help later in this book, when we're pinpointing what journey a company needs to 
make. 'To guide you through this book, we have distilled five main reasons to embark on a scaling 
journey. 


Drive revenue growth and 
outperform competitors 
with new business models 


Expand into new markets 


and geographies 


Increase quality, make oper- Deal with organizational 
ational expenditure savings challenges (access to qual- 
and shorten time-to-market ified personnel, ability to 


ramp resources, round the 
clock development, divide 
the work between different 
departments, and so on.) 


Develop innovative new 
products and services, 


innovate in current prod- 
ucts and setvices 


There are of course many ways to define and group different business drivers. We have chosen to 
use the findings from a Harvey Nash CIO Survey conducted in 2016, entitled “Key priorities the 
board is looking for an IT department to address". 


Where does your organization need to scale? Which of the business drivers are key to your organi- 
zation? You may identify several drivers to match your business plan and digital strategy. You have 
to bear in mind that this has to be a cross-organizational effort, where the current IT department 
needs to step up and be part of, or even take the lead. To define the role of the IT department is 
an essential part of the digital strategy. 


Let's get back to the SCALARE project room. The eight standard scenatios, the map and the 
compass on your scaling journeys, are compilations of the most common repeated patterns that 
the SCALARE team observed during the various case 

studies. In othet wotds, a scenatio based on teal life 

scaling experiences in companies that all shared 
similar drivers. 


This is how we should approach the scenar- 
ios. Which scenarios have similar drivers to 
ours? Since we may have several drivers 
to consider, our transformation journey 
could very well match several scenarios. 


Bottom-line: 


We have to get a clear picture 
of what dtivers we have. 


nkpmgeiosuneY“ 
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Not to waste time 


Get an overview by reading the map. 
Find out how the framework fits into your 


Picture by reading the Compass, 


Then read what Solutions there are by 


reading relevant journeys. 


436: 


The Scaling Management Framework 


Ways to find journeys relevant to you 


The journeys 


Travel Brochures and Travel Stories 


Your journe 


How you get there 
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Scaling software development is a complex enterprise that can be organized in a number of ways. 
Since the early days of computing, hundreds, if not thousands of software development methods 
have been proposed. What is becoming increasingly clear, however, is that the software develop- 
ment function affects the whole organization, not only its software developers. For example, as 
the software development workforce is expanding, the processes that are used may have to be ad- 
justed to facilitate large-scale collaborations. Developing more and larger software-based products 
requires consideration of architectural strategies such 
as the adoption of a software product line approach. 
The SMF covers three scaling domains to capture this : 
complexity: product, organization, and process. It also The Scaling 


captures the relationships between these domains. Management Framework 


To exemplify the scope of the SMF, let's consider the covers transformations 
fictive test tool company AutoTest. They have been f Р 
in three domains 


very successful in their local market, but now have the 
opportunity to expand to Asia. The SMF may help them 
in the analysis of their software development and sup- 
port organization. The SMF is not a tool for analyzing business models, but instead it can be used 


to analyze scaling changes triggered by for instance the introduction of new products, a specific 
customer requirement or a new support organization. 


The SMF can be used in several different ways to support the digital transformation journey. It 
offers systematic guidance for decision makers to identify scaling needs, to analyze scaling options 
and implement transformations in the three scaling domains. Since the SMF clearly defines begin 
and end states of the transformations, management can easily measure the success of the trans- 
formation journey. 


The framewotk is simple yet complete enough to suit all sorts of companies: small as large, local 
as global. It works equally well for companies that mainly deal with hardware but need to intro- 
duce software, as for companies that develop proprietary software and want to engage with Open 
Source communities. 


Drivers 


Current. organization Desired organization 
Inabilities Key Abilities 


^ transitions À 


Current process 


Desired process 


Current product Desired product 
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The SMF offers а multi-dimensional view on the software-scaling phenomenon. The SMF canvas, 
an integral part of the SMF, is a tool for understanding and describing the scaling of software 
development. It's designed to be visualized on a whiteboard, along with post-it notes. To the left, 
we have the present, and to the right we have the desired future. The transformation happens in 
between the two. 


It starts with top management to identi- Quality 
Бу the drivers, the reasons to scale. These 
are typically the outcome of a digitaliza- 


tion strategy. 


3 5 
© ^S 
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Next we observe the software development 

as a black box, focusing on performance, qual- 
ity and other aspects that can be measured with- 
out knowing how they work. We know what we 


Time | Cost 


spend and how much we generate from the their 
wotk. These are basically the complaints and wishes 
of our top management, matters we also could use to 
measure the success of the transformation. 


Soft Meo 
lo «€ 
Having all this, we're ready to dive into the black box, Ware 3 N 


the software model. Inside we have as well a present to 

the left and a future to the right. But foremost, it’s parted in the three scaling domains organization, 
process, and product. Our work is to find the root causes to the current inabilities, and for every 
cause come up with an idea of how we want it to be, ideally. This 15 done within all three domains 
and it is important that all inabilities are explained by at least one root cause. 


The gap between the present and the future defines the transformation, where the real work is 
carried out. It's also where we add the real value of SMF, with scenarios that include predefined 
transitions. In fact, the lot of this book is about scenarios; they are that important. If we know that 
part of our digitalization for instance includes one of the Open Source transitions, then we'll just 
add a note about it there, in the key transitions field. 
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Drivers Inabilities Desired abilities 


The drivers of the The inabilities that make the N The measurable 
need to change. transformation challenging. A definition of done. 


Current set-up Desired set-up 


Organization domain 


Process domain 


Product domain 


Transition 


The key activities that are needed to 
make the transformation possible. 


Drivers 


Drivers are the external factors that influence the software development. Previous drivers made 
you build your current product, ways of working and organization. But now, new drivers force you 
to create new solutions — to transform your software. 


We need to cleatly formulate why we want to make a change and scale our software development. 
If these drivers get too vague, also the solutions and eventually the implementation will be un- 
focused and sometimes never finished. Optimally, the drivers should be based on the company 
strategy. 


P, 


Reach new 
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It seems simple to create the drivers, but it often turns out to be quite hard to decide on what 
level the drivers should be defined. For example, 15 a demand оп “а more modularized product" 
a driver — or instead a possible solution to the driver to “get a more configurable product”? Is 
actually “a more configurable product” really a driver, or is also this a possible solution to cope 
with the requirement “to faster reach different markets"? We argue it is the latter and that the 
previous are solutions to be defined in the domains of the software model. 


We might for instance need to pursuit new market opportunities through expansion ога com- 
pany takeover. Or why not do as Amazon and start selling 
your internal development platform as a service? Do we 
We provide a short-list of five need to extend the functionality in our current offering? 
high-level drivers, and how they The mobile phone industry has made that, seeing the mo- 
can be translated into SMF tran- bile phone developed from being a communication device 
sitions. to also be our primary entertainment device. In regulatory 
requirements we need to comply with safety standards such 
as ISO 26262 (Road vehicles), or with software maturity 
standards such as CMMI (Capability Maturity Model Integration). Such requirements will inevi- 
table turn into drivers, since these are tickets to trade. 


In addition to external drivers, it is also possible to have internal drivers. An internal driver is 
something you want to achieve, as you believe it will help you move in the right direction even 
though no external customer or matket is requesting it right now. One such example is the com- 
pany culture. It might not directly affect the close-term business, but will most likely affect the 
long-term results. 


Since drivers are quite diverse and particular to every company, the SMF do not provide any 
model for analyzing and understanding drivers. Yet they need to be listed and understood before 
using the rest of the model. In this book, however, we provide a short-list of five high-level driv- 
ets, and how they can be translated into SMF transitions. 
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Software abilities 


Drivers represent the trigger for the transformation of a business; they are the reasons to drive 
a transformation in one of the SMF domains. They are the fuel that starts a journey to get from 
current software abilities to desired software abilities. 


Inabilities or growing pains are what currently stop us from achieving the desired drivers. The in- 
abilities are mostly visible outside of the organization, for instance by other organizations within 
the company or outside the company by customers. Abilities have to be measurable, in order for us 
to know if we're getting any better. When we measure the abilities, the organization is considered 
being a black box. 


Most abilities can be put into one of the following categories: 
Revenue — How much do we earn from our products or services? 
Cost — How much do we invest in development? 


Speed of development — How fast is the software being developed? This covers all aspects of 
speed, from adding or updating a feature to deliver the product or service. 


Speed of the product or service — What ate the response times for different use cases? 
Availability of a service, that is, the amount of time a service is usable. 


Flexibility — How fast can we change our development scope? This can be on a small scale like 


creating a variant, ог on a large scale like entering a new market. 


Quality — How good is the product or service that we are delivering? Quality includes many as- 
pects, such as safety, security, configurability, compatibility, maintainability, usability, serviceability, 
and evolvability. 


It is sometimes difficult to distinguish between a driver and a software ability. 


Let's use the taxi саг as an analogy. The dtivets ate the type of customers and their requirements, 
including school children, business people, disabled people, party crowd in need to make short 
as well as long drives. The abilities include for in- 
stance cost, speed and capacity of the car to meet 
the business needs. The driver's ability to avoid traf- 
fic jam and find the shortest way to the right address 
is probably the most important competition factor. 


Software abilities usually end up as Key 


Performance Indicators or Balanced Score- 
cards in the organization. 


Some abilities are not really sprung out of drivers, 

but can still be a reason for the company to make improvements. The SMF refer to these inabil- 
ities and drivers as growing pains. Examples of growing pains are when a company has trouble 
recruiting competent personnel or suffer from insufficient configuration management and version 
handling systems to manage parallel feature development. 
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When we wotk with the drivers and abilities, we treat software development as a black box. The 
black box is called the software model. 


The purpose of the software model domain is to: 


* Be able to analyze what we're bad at and what we need to 
improve in. 


* Forall improvements, analyze and describe dependencies 
to make the transformation. 


Opening up the box, we see domains as the software organi- 
zation, how they work, how they are organized and how the 
product looks. We cannot only focus on one of these domains, 
but need to look at the entire complex situation. The depen- 
dencies to organizations outside the box are usually many and 
intertwined. And it's not just the present, the future might as 
well require new relations to be established between the software 
otganization and the rest of the company. For instance, if the 


company wants to start using Open Source software, the legal 
otganization will be needed. 


The canvas 15 for this reason divided into the three domains: organization, process, and product. 
А domain covets all aspects that are important to analyze in order to define our important char- 
acteristics within the domains. They also define what changes we need to do within the domains 
to transform and fulfill your drivers. 


Our wotk is to make an inventory of the current ways we're working, and we should use post-its 
and document our findings on the canvas. With our drivers as a compass, it's time to start nest- 
ing. It is natural to begin with our inabilities. Are there any existing assets we can exploit and are 
there any roadblocks in the way we're working? It's time to ask all these questions we have оп 
out mind. 


In the following sections we describe the individual domains and their building blocks. 
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Product domain 
The product domain covers the software architecture of your product ог service. This is mote 
complex than just describing a software application as a monolith. The offering might be based 


on services rather than a single product. It might even include a complete ecosystem that defines 
how products and services can interact and how to configure these. 


The SMF divides this domain into three building blocks: 


* How the product is structured and managed duting development; the creation and manag- 
ing of the software source code itself. This includes how the software is structured into files 
and directories, libraries, modules, and interfaces. It also covers the tools that are used in 
handling of the code such as editors, version handling systems, and issue handling systems. 
This агеа is important to achieve reuse of code. 


* All mechanisms and tools that are used to produce the executable system from the source 
code. It includes all types of configuration and parameterization to build the product ог ser- 
vice, as well as branching in the version system. It also includes how the system is deployed 
to the end user. This is typically an important агеа for continuous deployment and to be 
able to create customized products. 


* How the product is organized when installed and executed by the user. It covers all aspects 
of interaction with the system when it's in use during operations of the software, including 
GUI interfaces to the system. Examples of architectures are client/server and cloud tech- 
nology. This is typically important for efficient execution and to enable incremental updates 
(new functionality or bug fixes) of installed software. 


The product or service is the final result of the whole software development lifecycle effort. 


ocess dor 


The process domain covers all aspects about how the product or service is developed and tested. 
This domain is divided in two building blocks: 


* Engineering covets all activities directly related to producing and testing the product. This 
includes processes for requirement, architecture, design, coding, integration, and уеййса- 
tion. It also includes all tools needed to support modeling, coding, testing and so on. The 
activities are preferable further divided into the three categories producing, verifying, and 
correcting. 


* Project management covets all activities related to steering, planning and controlling the 
engineering work, including prioritizing, estimation, risk management, planning, follow up, 
configuration management, change management, measurements, quality assurance, supplier 
management, etc. It also includes all tools supporting these activities. 


Organization domain 


The organization domain covers aspects such as how a company is structured, how the compa- 
ny's culture is and how are each individual employee treated. The organization domain is divided 
in four building blocks: 


* Structure — the organization chart. What sections, departments and teams are there? Who 
does what in the organization? How is governance implemented? What are the responsi- 
bilities and how are decisions made? Also described here is the physical structure of the 
organization — is there one site or many sites with distributed teams and organizations? Is 
outsourcing or offshore development in use? 


* Culture and leadership describes the general attitude in the organization, how decisions are 
taken and how changes are perceived and implemented. How is the attitude towards change 
and improvement? Is the atmosphere OK, are people speaking over the silo borders? Is 
there a lot of firefighting? Any pro-active work? Is it a learning organization? 


* People management describes how the staff is managed. This includes recruitment, perfor- 
mance management, and competence management. 


* Improvements desctibe all activities related to implementing and improving the product 
architecture, processes, and the organization. This covets as well descriptions, examples, 
templates, training, measurements, lessons learned, and improvement processes. 
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Transitions 


The key transitions are the most important activities in order to get where we aim; altogether they 
constitute the very transformation journey, the fun part where all the magic happens. 


The transition area of the canvas consists of a set of actions, each one representing a transforma- 
tion of the software model from a current state to a desired state. Transitions can be so general 
their descriptions turn into patterns. 


Examples of transitions are: 


* The organization chooses to outsource; development is made on both sites, but the outsourc- 
ing partner makes all test. 


* Changing the process from an agile process with morning stand-up meetings and other meet- 
ings on-demand, to a waterfall-like process focused on phases in which documents and other 
artifacts must be ready for hand-over. This requires recurrent meetings to discuss deliverables. 


* Increasing efficiency of knowledge transfer. This could be to set up an internal training pro- 
gram for new employees. A transformation such as this might not have any defined current 
abilities to overcome. 


Several cross-domain transitions are usually needed to address all desired abilities (that is, to fulfill 
the drivers). In the example above, to meet the requirement and lower the development cost, many 
changes are likely needed. No business situation is the other alike. We have to pay good attention 
to this phase. 


It all fits together 


To summatize, the SMF fulfill most companies' need to scale in terms of their existing or non-ex- 
isting software. 


Drivers and abilities gives the structure to describe the reason for scale and the main metrics need- 
ed to measure the improvements. Look into case studies with similar drivers and abilities as the 
business we want to change. Working with drivers and abilities is very important to understand the 
reason, why you want to scale. 


The software model with its three domains and their build- 
ing blocks gives a structure to desctibe the actual imple- 
mentation of the product or service. Each domain studies 
the building blocks and also the dependencies between im- 
plementations in different blocks. 


The SMF defines several standard 
change scenarios, but still most 


companies have to customize their 
unique set of changes in order to 
implement their particular drivers. 
The connection between the domains, how things works 
in each one of them, and the current inabilities encourage 
us to think through all domains and their building blocks in order to understand why we have the 
inabilities. 'This is part of the self-assessment to understand what needs to be improved. 


The transitions — capturing the needed change from current situation to desired situation is the 
most important part of the SMF. Experts within each domain will have to discuss possible chang- 
es and their impact. Yes, the SMF defines several standard change scenarios, but still most compa- 
nies have to customize their unique set of changes in order to implement their particular drivers. 
Exactly as фе SMF was intended to be used. 
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Why do we 
want to scale the business? 


What abilities Would we need to 
be able to scale successfully? 


Can We measure the 
abilities as KPls? 
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How the canvas can be used 


For this example, we will have a look at Spotify. Its service allows us to search for artists, al- 
bums, titles, labels and genres, and access music tracks from major as well as independent labels. 
Streaming of music has in many regions become the predominant way we listen to music. 


How did Spotity achieve to make the software service so successful? According to the vast amount 
of articles that have been written on the topic, they simply seem to have decided to “create the 
best streaming music service". We can assume this was their driver. What they 
intended to measure was the number of Spotify streams. This was their de- 
sired ability. The higher the number of steams (listeners), the more successful я 
they became. Let's try to express their journey with a few SMF post-it notes. 

Create the best 


| Streaming music 
Service 


To accomplish what their driver boldly stated, their software 
engineering department made this transformation. 


Most importantly, to stimulate motivation and innovation, they introduced an Agile Engineering 
Culture. They also organized themselves in loosely coupled but aligned Autonomous Squads 
(small, self-organized teams). A Squad has end-to-end responsibility of what they build (design, 
commit, deploy, maintain and operate). They did try the software development methodology 
SCRUM for a while, but decided quite early to skip this way of working. A more generic agile 
methodology was simply mote relevant for them. 


They introduced continuous delivery with small and frequent releases to their customers. The 
software atchitecture was changed to enable decoupled releases (synchronized releases were too 
time-consuming). Their product development approach was based on Lean Start-up* principles. 


** The Lean Startup. Crown Publishing Group. Eric Ries 
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We didn't intend this book to be read from start to finish — but you are more than welcome to do 
so. Instead, we've written this book with busy managers in mind — people, like you, who don't have 
the time to read the whole book carefully but only the sections that are relevant to your particular 
business. We've therefore organized this book along a set of journeys. 


The easiest way to read the book is to 
turn page and read through the brief sce- 
nario descriptions. So if you are interest- 
ed in Open Source you can just read the 
two Open Source chapters. 


a, 
ES 


A second way to read the bookis to have a look at the 
five categories of drivers, presented to the right on 
this page spread. If you for instance want increased 
revenues, then there are two journeys that can help, 
Servitization and Open Source (business driven). 


Drive revenue growth and outperform competitors with new business models 


J 2 
ЭЭ туз 


Develop innovative new products and services ог improve current products and services 


>» 


Journey 1 


> > Journey 3 


Journey 7 


Expand into new markets and geographies 


> > Journey 5 


Journey 1 Journey 6 
> > > > Journey 4 Journey 8 
Journey 5 


Deal with leadership challenges 


>> Bye >> =: 


Journey 1 - Co-operate т a community 


It is admittedly an irresistible temptation to us, getting free software. The cost to 
maintain a particular part of our system is sometimes far too high. It is possible to 
develop common components in cooperation with others and gain from proven, 
de-facto standard software. Entering this path would encourage us to further 
advance how we do business. 


Journey 2 - Building ecosystems 


By now we've been into Open Source development for quite a while. Even the 
management has acknowledged the contra productivity in just using free software 
without giving back, that sharing is caring. We imagine the ultimate Open Source 
strategy, to go beyond the communities and orchestrate out own ecosystem, to 
divide and conquet. 


Journey 3 - Add supplementary services 


Customers are getting more and more demanding: they want it all and they want it 
now, not to mention the fierce competition. Their offerings are basically the same as 
outs, equally or even better priced. Our product-oriented business slows us down. 
We need to move towards а service-driven business model. 


Journey 4 - Deliver 24/7 


Our customers ate dissatisfied with our ability to deliver what they want and when 
they want it. The time we need to test and deliver makes it hard to meet deadlines 
and steals time from development. As if it weren't bad enough, serious bugs have 
started to pass the loupe. If we can deliver continuously, we can refine our services 
by running more experiments and do-learn-adapt cycles with our market. 


Journey 5 - Pump up the volume 


We have the greatest product; every batch we produce literally sells out as soon as it 
leaves the production line. We need to throw in more people, to build the products 
faster and increase the volumes. Innovation 15 not a matter at this point, neither is 
the cost. What matters is how to get around the many dependencies between 
products, services and departments. 


Journey 6 - Agile and disciplined 


As manufacturer in the automotive industry, everything we do need to adhere to 
industry standards. The Niagara-like waterfall processes makes even small things 
take ages. We would surely benefit from a more flexible workflow, but the OEMs 
kill every discussion by saying "Agile software development lack discipline." 

We need to break this barrier. 


Journey 7 - Outside the box 


How about moving parts of out software development to India? Learnings suggest 
that it might be difficult, that a cost-reduction isn’t made that easy. Yet, highly skilled 
and talented engineers can still be recruited at a relatively low cost. Incorporated 
sensibly, we would gain back the flexibility we lack. We need to go offshore. 


Journey 8 - First things first 


It didn't happen overnight, but still, if we had staid calm when the business took 
off, we wouldn't have been in this situation. 15 additional programmers have joined 
the two of us, and our development process is getting a bit shaky. We need to adopt 
essential engineering principles and possibly re-factor the software architecture. 


Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 
International License (http:/ /creativecommons.org/licenses/by/4.0/), which permits use, sharing, 
adaptation, distribution and reproduction in any medium or format, as long as you give approptiate 
credit to the original author(s) and the source, provide a link to the Creative Commons license 
and indicate if changes were made. 

The images or other third party material in this chapter are included in the chapter’s Creative 
Commons license, unless indicated otherwise in a credit line to the material. If material is not 
included in the chapter’s Creative Commons license and your intended use is not permitted by 
statutory regulation or exceeds the permitted use, you will need to obtain permission directly 
from the copyright holder. 
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SCENARIO / 


«Think big. How to transform a software business in a good way» 


Copyright (C) «2016» <S.W. Scalare> 


This program is free software: you can redistribute it and/or 
modify it under the terms of the GNU General Public License as 


published by the Free Software Foundation, 
Open Source refers 


. : to software that has been 
(at your option) any later version. made available to the public 


either version 3 of the License, or 


and is free to use in any 

. | . . . application. 
This program is distributed in the hope 
that it will be useful, but WITHOUT 


ANY WARRANTY; without even the The source 
code is tied with a copyright 


license, giving any receiver of 
or FITNESS FOR A PARTICULAR PURPOSE. ШЗ urine 
modify and redistribute the code 

for free. Think of free as in free 
for more details. speech, not free beer". 


implied warranty of MERCHANTABILITY 


See the GNU General Public License 


You should have received a copy of the GNU General Public License 


along with this program. If not, see «http://www.gnu.org/licenses/». 


"Free software is a matter of liberty, not price. To understand the concept, 
you should think of free as in free speech, not as in free beer.” 


—-Richard Stallman 


The Open Source movement is several decades old, but it wasn't until the turn of the millen- 

nium that major companies entered the game. Traditional business wisdom had suggested that 

source code, which was seen as a “crown jewel" of a software company represented valuable 

intellectual property that should remain closed to maximize profit. With Open Source Software 
(OSS) development the effectiveness of this tactic is reduced 
since the source code is made publicly available. 


There is always someone who 
knows the solution to a given 
software problem 


The original intention with Open Source is that software is 
collectively developed, typically in an Open Source community 
characterized by collaboration, transparency and self-organiza- 
tion. This development model is an interesting value proposi- 
tion to companies, as development is potentially done quickly, involving hundreds of developets, 
who wotk for free. Involving many people to fix defects gave rise to Linus's Law*: given enough 
eyeballs, all bugs are shallow. In other words, there is always someone who knows the solution 
to a given software problem. 'This may also lead to new and better ideas from someone who has 
stood on the sideline thus far—these “lurkers” may decide to contribute after using the software 


for a while. 


Improve Accelerate speed 
innovation of development 


Le A 
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Share 


deve lopm ent 
COSts 


In recent years, this image of OSS developers has become outdated, and many companies are 
now actively participating in OSS communities for a variety of reasons. 


Howevet, no matter the business incentives, the initiative to start working with OSS communities 
is almost always taken within the development organization. As any development organization, 


they simply need to: 


Ye А claim formulated by Eric S. Raymond, named in honor of Linus Torvalds 


e Increase Innovation — фе drive to include novel and innovative software in the solution, as 
well to participate in the communities were this innovation occuts. 


* Reduce Time-To-Market — as a solution is available for free, and much of Open Source 
software has become de-facto standard, it can reduce the time for an offering to reach the 
market. More so, by active involvement in a community a company may influence its devel- 
opment to take a beneficial route for the company's offering. 


* Reduce maintenance costs — sharing the development and maintenance as conducted in an 
Open Source community, substantially reduces the overall operating expenses. 


Even if the work with Open Source preferably ought to be sanctioned by management it often 
starts as skunkwork*. 


Those Open Source drivers are particularly appealing for the development organization whose 
software is characterized by a large heap of legacy and proprietary code that haven’t been main- 
tained and modernized for a long time. 


When the cost to maintain the code supersedes what is invested in new features development, 
Open Soutce offers an irresistible temptation for engineering, Business as usual — to constant- 
[у postpone innovation and delay novelties in the offering to the future — simply isn’t a viable 
option. 


A skunkwork project is a small and loosely structured group of people who research and devel- 
op a project primarily for the sake of radical innovation. 


So the engineers decides to accidentally" use Open Source as a novel way to cut corners when 
solving development challenges they have at hand. This is very common, but of course not the 
preferred way forward. Quite likely, they don't have formal approval from the management. 


‘е Е Aik | Aft ment [2E | n | T doesnt 
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The reason they don't include management and keep doing skunkwork may vary. The not-in- 
vented-here argument is often heard. Management may not trust third-party code. Until only a 
few years ago, Open Source was considered by most as a hacker's phenomenon and a headache 
for the Legal department. The threshold to explain what Open Source is really about and why 
software development would benefit from it might appear like an impossible mission. On the 
other hand most Open Source newbies are everything but knowledgeable about legal obligations 
that come with Open Source. Neither are they likely to comprehend how to truly leverage from 
Open Source as long as they only consider it as being “free as gratis" code. Both development 
and management need to learn about it. 


Most optimally the use of Open Source ought to be introduced ш a company as a coordinated 
and strategic activity, on which the following pages will elaborate in more detail. 


One of the goals could be to get the entire organization seeing how Open Source saves money 
and improves innovation, to get it to use Open Source software more regularly. But foremost, 
control has to be established. The Open Source activities need to be agreed and standardized 
within the organization. 


The company introduces policies, procedures, organization and hopefully some training as well 
to harness the Open Source practices, very much for securing the fulfillment of legal obligations 
that follows with Open Source. 
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However, introducing Open Source in an organization raises some concerns too. Training all 
staff on the fundamentals of copyright law and Open Source licenses is costly and might offer 
a challenge for engineers to grasp. It could be hard to implement and defend the added cost for 
the necessity of conducting the Compliance work that follows with Open Source. 


Awareness on costs related to Open Source arises, both as a threat (potential litigations for li- 
cense breaches), but foremost as an opportunity (faster development and reduced maintenance). 
Gaining the benefits of the latter will open for allowing developers to engage in Open Source 
communities, including source code contributions, as that will soon will be discovered that is the 
only feasible way to influence Open Source communities. 


BRANCH OUT CALL COMMUNITY CONTRIBUTE 
WHaT YOU WANT FOR DISCUSSION YOUR CHANGES 


000 -o- -o- -o- O O O 


MAKE YOUR CHANGES REVIEW AND DISCUSS 


Initially, the likely main challenge for management is that Open Source is perceived to raise an 
unknown legal risk. Management may also perceive that with Open Source unknown technology, 
with unknown effects on the company’s offering, would flow in uncontrolled, and worse, that 
valuable corporate Intellectual Property may flow out uncontrolled. Typical legal risks include 
copyright and patent lawsuits and to lose control of software and other intellectual property 
rights. In fact, to handle these matters comes at a bargain in relation to what we gain, compared 
to continuing the business as usual. We just have to deal with it properly. 
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Open Source governance policies, processes, tools and organizational structures will be required. 
Three fundamental processes are essential; an Intake process for legally vetting code that de- 
velopment intends to use, a Compliance process for ensuring that code follows the terms and 
conditions of Open Source licenses, and a Contribution process for the approval of code to be 
released to an Open Source community. 


We will need organizational roles 
such as the Open Source Officer 


and specific roles for compliance 
and contribution management. 


These processes will call for creating new organizational roles such as the Open Source Officer 
and specific roles for management of compliance and contribution. The new roles will have to 


Differen tator 


possess mandates that management might be unwilling to share. An implication that is seldom 
fully understood is that the current product management has to let go parts of the requirements 
and the product definition. By its very nature, the power over the product definition will drift 
towatd the engineers and the Open Source communities. 


Getting control of the legal matters requires legal and patent counselors to be involved in the 
software development process. The counseling will be around copyright, patent, IP, and trade- 
mark laws. As contributions to Open Source communities become frequent, a larger organiza- 
tion could benefit from establishing a governance body, a so-called Open Source Board. Typical- 
ly such an Open Source Board vets and approves contributions, while considering both business 
needs and IP protection needs. Such a body would also naturally be mandated to issue corporate 
policies on Open Source. 


To most developers this goes without saying: Integrating Open Source software is no different 
from integrating any 3rd party software. The software architecture has likely to change to host the 
Open Source software artifacts. If it's already modular, just with a few cuts in the wrong places, 
the adaptation will be a smooth job. If it's monolith, a major refactoring of the software is likely 
required. The Open Source software’s APIs must in turn never be changed without approval, to 
facilitate contributions back to the Open Source community. 


To some companies, the Open Source software becomes key elements in both the company's 
offering as well as its innovation. The companies’ engagement in Open Source has to get direct- 
ed and has to evolve to an Open Source strategy that encompasses development goals as well as 
business benefits. They need at least to influence the community to gain some control of the de- 
velopment in the community. The incentives to do this ranges from simply sharing development 
costs with partners and use common technology, to give the company a competitive edge on its 
own offering while disrupting the competition. In most Open Source communities the control is 
i gained by becoming a champion contributor. 


Introducing Open Source development sensibly and cross the organization as a strategic and co- 
otdinated activity, will likely pay off in a mote competitive product offering. Getting state-of-the 
art Open Source technology to a reduced cost and with a shorter lead-time isn't that bad, after all. 


One more thing 


In many large companies, software is considered the property of the team that de- 
veloped it and 1$ not shared freely within the company. Inner Sourcing 15 the prac- 
tice of developing and sharing software openly within the company but not beyond 
(in contrast to Open Source Software). 


The companies get many advantages of Open Source software and avoid at the 


same time IP and license complications associated with open source software con- 
tributions. The primary benefit is however the collaborative spirit and organiza- 
tional flexibility that arises from teams who are able 
to contribute improvements to each other's code. 
In addition, there is a direct benefit in reusing code 
and competence, something that will not only reduce 
development cost but also increase speed and overall 


quality. 


There are many other reasons to consider Inner Sourc- 


Volunteer contributors will 
spring up freely to contrib- 
ute to interesting projects 


ing. An open environment facilitates increased aware- 
ness of the software and helps to break down barriers between teams through the 
use of common code, tools and methods. Having less duplication of development 
will cut costs. Volunteer contributors will spring up freely to contribute to inter- 
esting projects, which may lead to shorter time-to-market. Since contributions are 
under large-scale scrutiny, developers get aware of their reputation and motivated 
to write “good” code. 


Moreovet, since they are familiar with a standard set of common tools and infra- 
structure, developers can be more easily transferred to other projects or products. 
This in turn will reduce time-to-market, as project start-up time can be reduced. 


Accelerate speed of development 
Improve innovation 
Share development costs 


Not-invented-here culture Open Source Competence 
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Control of APIs 


Accidental use of 


Open Source Open Source governance tools 


Get inspired 


This scenario has been based on case studies of different companies that have made this 
journey, to scale with Open Source. Learn from their experiences, what they gained and 
what they had to overcome. 


Sharing is caring 

А quiet revolution was changing the world for the software engineers at the mobile phone 
manufacturer Sony Ericsson. An Open Source force of epic dimensions had just been 
released. This case study is about the manufacturer who embraced a powerful engineering 
movement and created an Open Soutce strategy that, although there were initial business 
benefits, primarily encompassed goals set by the developers. 


A thriving Open Source culture behind the wall 

Open Source projects really can't be beaten in terms of development power. This case 
study gives insights into a multi-national mobile network equipment supplier, which expe- 
rienced a similarly quiet but powerful Open Source revolution, but behind the company 
firewalls. Read about how the development organization found ways to utilize resources 
and created an Internal Source culture. 


Keeping the doors open 

Traditionally, door-opening solutions wete about locks and keys. Nowadays, they are still 
about mechanics but use а lot of electronics and software. It is not just a piece of hardware 
anymore. The solutions even tap into the industry of services. And there is of course Open 
Source software usable also in this particular business. Read about ASSA ABLOY, who 
went from using bits of Open Source software they found, to get really professional about 
it and implement an Open Source strategy cross their organization. 
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Sony Mobile's Open Source journey began with general curiosity among developers at Sony 
Ericsson's development department. This led eventually to an investigation whose results were 
so convincing that the management took the bold decision to shut down the work on propri- 
etary operating systems and invest wholeheartedly in the Open Source based Android operating 
system. The new era began in 2010 with the Android telephone Xperia X10, and today all its 
smartphones ate based on the common Android platform. 


The company sees a whole host of advantages in belonging to the Open Source movement. First 
of all, it increases the pace of innovation and development, simply by having a larger number 

of developers focusing their creativity on a single task. And when someone comes up with a 
clever solution, the entire network has a share in it and benefits from it. As a result, everyone is 
constantly creating new opportunities for everyone else. Without Android, Sony Mobile don't 
believe it would have existed. More than 85 % of its software is based on Open Source. 


It realized eatly that an Open Source project must be transparent and encourage participation 
and collaboration. Management had to make Open Source a part of their corporate culture. 


R & D and Legal, hand in hand 


Close collaboration with the Legal department has played a central role. A success factor was the 
eatly establishment of a “double-command”, consisting of its chief strategist for Open Source 
and a lawyer at its Legal department. The duo has been instrumental in changing the business 
and mindset throughout the development organization. 


The Legal department recognized in the initial stage that Open Source was perfectly solid and 
valid from a legal standpoint — acquiring Open Source was essentially the same as any other kind 
of third party software. They also noted that Open Source would become utterly essential for 
the company’s survival from a business perspective. In this way, the Legal department became 

a key player in persuading executive management that the necessary culture shift not only was 
possible, but also would be warranted by governance under Legal's supervision. 
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A major challenge was to fight the notions that Open Source was mainly a software development 
concern and something of slight headache to the Legal department. These earlier viewpoints 
dominated the thinking in Sony Mobile's early days of Open Source. It was seen as OK to use 
because it was “Нее of charge". In the last couple of years, as the success of Android unfolded, 
the mindset changed completely. 


Eventually, software developers and lawyers developed mutual trust. The duo translated legal 
concerns to developets, as well as the other way around, educated Legal on engineering con- 
cerns. The resulting trust has also led to executive management being much more daring in 
taking business initiatives involving openness and collaboration — even when it involves the 
competition. 


Sony Mobile Open Source Maturity and Strategy model 


Today, not only does most of Sony Mobile use Open Source for everyday development, but the 
company has also established itself as the largest external contributor to Android development. 


Recently, it has also taken several initiatives in the marketplace in leveraging Open Source in tilt- 
ing business to its advantage. It is making progress in achieving position on the higher levels of 
the Sony Mobile Open Source Maturity and Strategy model, the levels when business concerns 
come into play. 


Its Maturity and Strategy model has five levels. The first three represent stages that are mostly 
driven by engineering and development concerns, whereas the last three levels are more business 
driven. 


Even if the model isn't a tool for scaling into Open Source development, the model has proven 
to be very effective to communicate where it is and where it aims. It's a model to measure matu- 
rity and to set the strategies that wotks with both developers and management. 


Engineering Driven 


Level 1, “Accidental” 
А stage of discovery and early awareness where developers 
explore and “play around" with Open Source software. 


Level 2, “Repetitive” 

A company begins to make use of Open Source software 
in a governed way, seeing that it can reduce cost and 
improve interoperability. 


Level 3, “Directed” 

Open Source has support from executive management, 

is incorporated in the product strategy, development aims 
for champion communities and collaborations widens. 


Business Driven 


Level 4, “Collaborate” 

Open Soutce projects and collaborations are run to achieve 
both technical and more so business goals which are able 
to change the market logic. 


Г Level 5, “Prevail” 

The company has developed a fully-fledged Open Source 
company culture, with full strategic support from the top 
management, to the extent the company is able to disrupt 
entire markets. 
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ye Copyleft (a play on the word copyright) refers to the copyright licensing scheme used when mak- 
ing Open Source contributions. 
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Adam is a senior software developer at a big Swedish company in the telecom business. Some 
years ago, Adam realized that many projects and developers mote or less developed the same 
code. There had to be a way to reuse code and competence across the company. Since he was 
already familiar with Open Source software he thought a similar approach would also work in- 
ternally. So he made his own software repository solution available to his colleagues so that they 
could start sharing code and projects. 


The rumor spread and more and more colleagues started to use Adam's tools for sharing code. 
Later, several teams decided to manage all their internally developed tools by using this reposi- 
tory installation, which still was running on Adam's PC. This was just the start. Ву the word of 
mouth and some internal blogging, the initiative spread within the company and grew to such 
proportions that also other managers realized their organizations depended on Adam's code 
sharing initiative. 


The IT department had at the time licensed a commercial system for code life cycle management 
but it turned out that the developers rather desired to use Adam's tools. A few attempts were 
made to get developers to use the commetcial solution, but Adam's solution was already too well 
established within the organization. 5 yeats later, the Inner Source initiative had grown to a stag- 
gering 5.000 projects and 16.000 people. And the only support Adam provided was some short 
documentation on how to use the tools and some thoughts on Inner Sourcing through his blog. 


The company has since long realized that this was a too important and powerful environment 
to be managed and driven by one person on a small PC. Eventually, they also switched to use a 
standard commercial system for code sharing and collaboration. 


The main reasons the Internal Source initiative grew so strong in the company are the low entry 
barrier of the tools and the extremely short lead-time for starting up a new project. Developers 
like it because it 1s so easy to use and that they instantly get up and running. 


Internal tools are very often first out to be developed in an Inner Sourcing environment. Adam 
estimates that their internal tools development became 10 times more efficient in terms of 
resoutces, by this initiative. A side effect, but a very powerful one, was that the company also 
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gained full transparency in development made by third parties, since they as well started to use 
the Inner Sourcing environment. 


A key success factor behind introducing Inner Sourcing was the corporate culture. The teams 
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are fairly autonomous and well empowered to define and use their own methods and ways of 
working. Adam states that to succeed with Inner Sourcing, the company culture has to be built 
on trust and empowerment of teams and individuals. 


Even though tools still are the most common Inner Source projects within the company, also a 
few commercial products rely on Inner Sourcing. Adam is convinced that Inner Sourcing will be 
instrumental to tackle future capacity and time-to-market challenges. 
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One very clear example of a company that has moved from hardware-based products to soft- 
ware-intensive solutions is ASSA ABLOY. This company is a leading manufacturer in door-open- 
ing solutions and a matket leader in Europe, North America, China and Oceania. The company 
was formed in 1994 through a merger of ASSA in Sweden and Abloy in Finland. Since then, it has 
grown from a regional company to an international group employing a workforce of over 46.000. 


Traditionally, door-opening solutions were about designing and manufacturing locks and keys, and 
as such, this business is very much dependent on the price and availability of steel as the raw ma- 
terial. While steel and mechanical solutions are still important, most of the costs of the company's 
solutions are spent on software development. Modern door opening solutions involve a consid- 
erable amount of electronic circuits and software to control them. Furthermore, door-opening 
solutions now also start tapping into the industry of services. The days where a lock was just a 
piece of hardware are over. 


ASSA ABLOY has developed software for decades for its back-end door-lock systems and Open 
Source isn’t a new thing for them. Indeed, ASSA ABLOY were well aware of the benefits that 
Open Soutce Software can offer, such as reducing development time, increased security (as some 
of the relevant OSS components are thoroughly tested), and high quality products. However, 
there was never a company-wide strategy or policy around Open Source. As is common in many 
companies, different engineering teams first brought in Open Source in an uncontrolled way. As 
the company realized the increasing strategic importance of Open Soutce, the company started in- 
vestigating tools and policies for using Open Source more consistently. This new task was assigned 
to ASSA ABLOY's Shared Technologies division, which is responsible for developing common 
software assets and scouting new technology. 


ASSA ABLOY Shared Technologies understood that becoming fa- 
miliar with the various Open Source licenses was key in order to 
become compliant. To that end, a tool was used that automatically 
seatches and identifies Open Source software in their code base. How- 
ever, soon the company realized that merely using a tool wasn't suffi- 
cient to engage with Open Source products. Engaging in Open Source 
also requires developing an understanding of the Open Source software 
lifecycle management, and how to align this with the company's internally 
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developed software. A new policy were needed before making significant investments in tools. 


ASSA ABLOY took a number of steps to establish an Open Source engagement policy. First, the 
company sought advice from Open Source consultants to be better informed about the conse- 
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quences of using Open Source software. Second, prior to rolling out the newly defined policy and 
process, all engineers, project managers and line managers in the Shared Technologies division 
were enrolled in a training program on these issues. 


The company's process and policy defines a structured way to manage different Open Source 
software, which includes the following key processes: 


* Acquisition. This process is concerned with avoiding risks related to IPRs, patents and secu- 
rity threats. Furthermore, it considers understanding the availability of Open Source software 
and developing a make-buy-share strategy for adding software components in their products. 


* Compliance. The Compliance process deals with license matters and how their proprietary 
software and new Open Source software can coexist. 


* Contribution. The conttibution process defines how the company should interact with Open 
Source software communities. 


А key challenge was really the absence of a company-wide Open Source policy. It was very dif- 
ficult to leverage and get control of Open Source Software without it. Another challenge, one 
shared with many other companies, is how to more actively engage with 


Getting the teams more Open Source communities. Even though the company management en- 

involved in communities courages participation in communities, the development teams are still 

is truly a challenge mainly users, not contributors, of Open Source software. Achieving this is 
truly a challenge. 

ASSA ABLOY Shared Technologies is clearly on a journey where it not only sees the benefits from 


using Open Source in their products but it also sees the value in actively engaging in communities, 
in otder to actively participate in the evolution of Open Source products that it has a stake in. 
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This scenario is about 
how to go from "only 
creating product value from 
an Open Source community 
to drawing comprehensive 
gains from orchestrating an 
own ecosystem. 
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The ultimate Open Source strategy is to go beyond the communities and create an ecosystem that 
becomes the business and not just supports the business. At its furthest implementation, the eco- 
system has disrupted the entire market logic and became the helm of the market. Google and Ap- 
ple are great examples of companies that made exactly this. Google's Android is basically nothing 
but a collection of 60 to 70 Open Source software packages. Similarly, Apples OS X and iOS are 
highly dependent on Open Source (BSD Unix and Web Kit among others). The key aspect of 
their success has been their ability to join together Open Source communities and blend differen- 
tiating (often proprietary) parts of their products with commodities offered as Open Source. 
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Open Source is a game changer to the business, since parts that are contributed as Open Source 
also gets commodities and brings down the value of the offering. The business drivers are 
mostly a product of the change in the business model. Typical goals that companies aim for are 
basically to: 


* Accelerate growth of business — to expand the market both in terms of a broadened offer- 
ing and to grow higher in the value chain 


。 Disrupt market entry barriers — to gain access to a market with an open offering, while rais- 
ing the bar for proprietary and non-collaborative businesses 


* Open up for alternative business opportunities — to benefit from alternative revenue 
streams since the revenues for software alone disappears 


To achieve this requires great flexibility in creating new revenue streams. They can be based on 
an extended business model (when alternative revenue is collected from something related to 
the core offering, e.g. a service fee), an indirect business model (when revenue is mainly collect- 
ed through a device or a hardware offering) or an asymmetric business model (when revenue is 
collected from a source unrelated from the core offering). An example of the latter is Google's 
Ad-Search business that benefits from providing Android for free. 


Open Innovation (OI) is the dominant model of gaining external benefits and generating spin- 
offs from openness. 
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Illustration based on pieture From presentation of Open Business Models by Henry Chesbrough 


The key desired abilities we strive for — to be able to reach, create and orchestrate an Open 
Source based ecosystem, an ecosystem that also could be described as a community of 
communities — require a collaborative business model. 
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Howevet, a journey like this can only start once a company's use of Open Source сап be said is 
being directed, when the company has gained such support from the executive management so 
the use of Open Source software is paramount of the product management. (See the chapter 
Co-operate in a community.) At this stage the company is well versed on the engineering and 
legal aspects of Open Source. The company's knowledge level on Open Source is satisfying to 
the extent that directives and policies are relaxed and some automation of the governance pro- 
cesses has been introduced. Moreover, Open Source technologies have become such a valuable 
element of the offering it is песеззагу to influence the control of the Open Source develop- 
ment. The product offering itself has also gone through a transformation. Fundamental is that 
it has a modular architecture, but more, it's likely that the product is connected to the Internet, 
prepating the offering to be extended by cloud-based services. 
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Although the entire idea with building an ecosystem is to scale the business, it can still be а 


challenge for the management to recognize how Open Source as a phenomenon can be used 
as a business tool. The management will have to explore radically different market logic, and 
in this, they have to fundamentally question what really is the company's core offering and 
how alternative revenue streams then can be created. The cemented truth that “proprietary 
Intellectual Property is paramount for a company's success" will often be proven wrong. 


Directed by 
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Most essentially comes with Open Source a participatory culture. Custom- 
ers are moving from being passive receivers of purchased solutions to ac- 
tively involve themselves in the development of the product offering itself. 
Many companies have created Developer Programs to catch and nurture 
this kind of culture, opening up for customers to influence the develop- 
ment of the product offering. 


A Developer Program is very often seen as the seed of an ecosystem. 
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orative business model, а more supporting and coaching leadership | 
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flat, network-oriented and self-managed organization, which better create and direct 
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| ecosystems 


PE |. The current product Management will obviously be under fire since much 
ns of the product definition will reside outside the organization. It's important 

| though, that the role for the product Management is adapted to envision 
| | future offerings rather than define the product in detail, as the latter will drift 
Й = towards crowd-based requirement engineering set-up in the ecosystem. 


Directed by 


The Legal department will deepen its collaboration and start building legal frameworks for 
novel offerings, as part of the company business development. 


However difficult the transformation of management might appear, a major growing pain will 
be to recruit the necessary talents in order to build the ecosystem. This accounts in particular for 
cloud-based services and the necessary support systems for the new business it will offer. Those 
people are currently amongst the most sought after in the industry. 
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To summarize, software companies can benefit from creating a software ecosystem based on 
shared Open Source, including partners, customers, end users and sometimes competitors. The 
latter is not too far-fetched as many competitors may be entangled in the same Open Source 
development, being R&D partners in an industry-wide collaboration. Such collaboration signifi- 
cantly raises the market entrance bar for competitors with proprietary offerings — who would 
have costlier development and maintenance as well as the burden of alone having to prove its 
value on the market. 
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This scenario has been based on case studies of different companies that have made this 
journey, to scale with Open Source. Learn from their experiences, what they gained and 
what they had to overcome. 


ES Pushing the boundaries 


There are companies that relies on cloud technology infrastructure more than others. If 
they also happen to include gigantic data transfers in their offerings, it's not unlikely that 
they will have a very close look into the ecosystem Netflix have created. Read about the 
company that employs more than 700 engineers that more or less gives away everything 
they create just to keep the business flourish. 


Servitization 
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Take again Netflix, who provided a DVD- 


by-mail service before creating their vid- 
eo streaming service. They likely made 
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next chapter in this book, "Add supple- 
mentary services. Read it as well! 
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Рог the last years, Netflix has accounted for more than a third of the Internet traffic streaming 
into North American homes every night. That's more than the combined traffic of the trailing 
contenders such as YouTube, Hulu, Amazon, and iTunes. 


At any moment, Netflix draws upon 10.000 to 20.000 servers running in Amazon data centers. 
The computers handle customer information, video recommendations, digital rights manage- 
ment, encoding of video files into different formats and monitoring the performance of the 
systems. When a new device as for instance an upgraded game console or a smartphone comes 


along, Netflix uses thousands of extra servers to reformat movie files and to serve the new usets. 


Netflix has a renowned reputation for pushing cloud computing and Amazon Web Services to 
its limits. 


From the very start, Netflix has been forced to build much of the software from ground up. 
Since they rely on Amazon data centers, their 700+ engineers focus on tools that for instance 
automate the way in which thousands of cloud servets are started and configured. Like Google, 
Facebook, LinkedIn and Twitter, Netflix depends largely on Open Source for much of the soft- 
ware that underlies their operations. The companies compete in fact on who's paying most for 
the most clever engineers, to give away their outcome so that others can build on top of it. 


Giving away their technical wizardry for free and to rely on 4.000+ volunteer programmers 
makes perfect sense to Netflix. At the end of the day, they will gain from more robust code that 
has been infused with bleeding-edge innovation. 


Together, these companies forge the cutting-edge Open Source cloud computing technology 
that mainstream companies will use in the years to come. It is essential to Netflix to have a lead- 
ing role in streaming video cloud technology to maintain their forerunner market position. They 
have to accept that their competitors — old ones working with cable technology as well as new 
ones working with the web — in a flick can become their partners. 


To ensure the case, Netflix has created a great arsenal of open-source cloud computing technol- 
ogy. They have tools to install preset packages of software on Amazon servers, to reconfigure 
them and to test them without causing any downtime. The so-called Simian Army, another set 
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of applications, purposefully try to wreak havoc on their infrastructure in a bid to find holes and 
performance problems. Chaos Monkey, for instance, simulates small outages by randomly turn- 
ing services off, while Chaos Kong takes down an entire data center. 


Eventually, Netflix wants to use an open source platform. Instead of releasing cool but disparate 
projects, the company wants to put together a cloud management system that software devel- 
opers can poke and prod and advance. A platform would provide an opportunity to widen the 
offering beyond the core business. 


Interestingly enough, Netflix’s Open Source strategy is not of any particular old age. It all start- 
ed in 2011. Only a few yeats later, they had built a bustling community and ecosystem. Today, 
Netflix is crystal clear on their corporate view on Open Source. It is not only a mean for devel- 
opment — it's a strategic weapon for their business. We should expect the “More to come, stay 
tuned!” screen on their business outlook. 


* 
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In essence servitization is a transformation journey - it involves companies develop- 
ing the capabilities needed to provide services and solutions that either supplement 
or replace their traditional product offerings. Recent technological advances such 

as cloud computing, big data analytics, mobility and social media have enabled the 
servitization trend. 
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Servitization is used when a company introduces a service offering as a means to further satisfy 


their customers' needs, to enhance profitability, to gain a competitive advantage or to avoid com- 
peting with low-cost countries on a cost alone basis. The theory suggests there are three levels of 


Low cost 
competition 


product-to-service transformations, but there are no clearly delineated boundaries. It's rather a 
matter of how your value proposition is defined. 


To completely replace a prod- 
uct with a service requires a 
long-term investment. 


In this case there is no product 
or owner. The service is con- 
sumed at the same time as it's 
delivered. 


Companies that made this 
journey can for instance be 
found in the entertainment 
industry. 


Example: Netflix 


A middle-road approach is to 
keep the product and trans- 
form the business model to 
be subscription-based. 


The owner of the product is 
now the service provider. 
Companies that made this 
journey can be found where 
buying the product requires a 
substantial investment. 


Examples: Rolls- Royce with 
its Power-by-the-hour aircraft 
engine program and Xerox 
printer service. 


Least complex is to keep the 
product and purchase-based 
business model, but add 
supplementary services such 
as maintenance and premium 
programs. 


The owner of the product is in 
this case still the customer. 
Numerous businesses suc- 
cessfully adopts this model. 


Examples: Ericsson offers 
maintenance of their tele- 
communication equipment. 


Turning a legacy product business into a cloud-based setvice business has become the Holy 
Grail of the software industry in recent years. Being able to provide customer value by making 
services that for instance use data from the billions of Internet of Things sensors, 
turns out to be a money-maker. It's not that easy, of course. You have to make sense 

of the data, turn it into knowledge and meaningful actions. Parking place sensors 
are practically useless if you can't come up with a clever way to help your customers 
quickly find a free parking place. There are numerous examples of companies that 
have successfully made the journey to replace their products with services and by that 
increased their profit. Yet, it's far from a done-deal, whereas many also fail. Most ca- 
sualties are usually claimed during the transformation phase. Learning from the pitfalls 
and how successful companies made it, significantly increase a company's chance to 
succeed. The solution described in this chapter has proven to be fruitful. 
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Consider fot а minute the dynamics within the management group. Who gets to talk most on the 
management group meetings? This will change. Substantial amount of time and resources that are 
currently allocated to track and report development and manufacturing will decrease to an abso- 
lute minimum. Sales, or rather the new function that sales will have to become, will get the most 
attention. Expect clashes since not everybody will be able to free themselves from their previous 
roles and traditional ways to run the business. 


Being able to offer a service is a huge opportunity that can completely change yout business mod- 
el. Don't think too long about it. Setting up a profitable service takes time and it's not unlikely that 
your competitors have already started. Agility will turn out being your key ability. 


Regardless where you aim in your scaling effort, it cannot be emphasized enough how 
important it is to start in the management team. First priority is to change every- 
body's point of view, to stop gazing at the Gantt chart and 

instead seeing the customers. 


Another priority, and indeed a great challenge, is to develop a scalable, 

repeatable and profitable business model. In terms of creating it, there isn't 

really any difference between an established product business that wants to start a Set- 

vice and a start-up business. They have an idea of a service business but the value proposition 
hasn't been carved out entirely. Both have to ask and challenge the same questions. 


Service business Customer Service 
model unknown Development business 
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To support in finding the answers, many successful, web-based companies — including Spotity, 
Dropbox, Airbnb and IMVU - use the customer development method described in the book 
“The Lean Startup".* It's a very good start, no matter from where you come. 


** The Lean Startup. Crown Publishing Group. Eric Ries 


Customers have to get value day after day, month after month, to stay as such. They have уегу high 
demands on availability. When at least 99.9% availability is expected on a normal service, there's ab- 
solutely no room for temporary glitches. The ITIL 2011 has shown to be a great source of knowl- 
edge to support how to get there. Study in particular the Service Management guidelines. 


| Service 
management 


b 


How do you provide a service that customers willingly pay for 
month after month? You have to get to know them and demonstrate 
that your service adds value to every one of them, every day. The 
technology gets secondary — the customer experience becomes pri- 
mary. What are their needs? Understanding your customers and their 
behavior will be key. How do they use your service? Fortunately, it’s 
much easier to monitor customer behavior when they're using services 
than it is when they're using products. 


A huge advantage with software services is that you can prototype im- 
provements and new features in a small scale without having to make major 
investments. The service can grow as the business grows and your customers 

can benefit from new functionality instantly. Purther, being able to use live usage 
data and prioritize development that improves the service, makes this advantage even 


mote valuable. 


The development wotk lends itself to be carried out in an iterative way, to create a so-called 
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minimum viable product every week, or even every day. There are Ag- 
ile development techniques such as Continuous Delivery, A/B testing 
and DevOps* that perfectly support this way of working. An iteration 
would only comprise a few of the highest ranked work items in a pri- 
ority-ordered list, called the backlog. 


After having provided the new features to your customers, you can 
measure, analyze and improve them. If a feature doesn’t live up to 
the customer’s expectations, the design has to be improved. New 
features are not taken away from the developer's backlog until the 
customers show, either through surveys or logged behavior, that ev- 

erything works nicely. 

Simply put — fail fast, learn fast, and improve fast. 
2 WS 


This is a never ending cycle of making a hypothesis about a new cus- 

tomet feature, building the minimum viable product, looking into how 

it's used, learning from it, making a new hypothesis, building, releasing, ana- 

lyzing and learning, and on and on. There will always be high time to improve 
either the business model or the service. 


Expetiences have shown that the companies that have created small, autonomous teams 
that work as start-ups are the ones that also are the most successful. Many of them work ac- 
cording to the customer development methods described in “The Lean Startup". 


¥ A practice that emphasizes the collaboration and communication 
of software developers and IT professionals 


The challenges are plenty fold, as can be expected. While many companies are successful, many 
also have difficulties in seeing the benefits. Most commonly, they experience problems with: 


* Conflicts in the organization 
* Difficulties to sell solutions that aren't tangible 
* Creating a setvice oriented business culture 


The pit holes along any servitization journey are numerous and failing to get around them will 
inevitably jeopardize the transformation process. But, there's no reason to be discouraged. De- 
spite a massive change in business and ways of working, the servitization journey is proven to be 
truly worthwhile. Research shows, for instance, that successful service providers clearly gain: 


* Customer loyalty 
* [ncreased revenue and profitability 
* Robust cash flow and revenue streams 


The servitization canvas helps to avoid making old mistakes in getting these gains. 


Customer expectations 


Gaining competitive advantage 
Financial incentives 
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Get insights 
This scenario has been based on case studies of different companies that have made this 


journey, to scale with Servitization. Learn from their experiences, what they gained and 
what they had to ovetcome. 


ES Adding Internet to things 


—^ Read about the company that boosted their B2B sales by spicing their lawnmowets prod- 
ucts with IoT. 


E Boosting product sales by services 


Learn from the company who aimed too high with a worldwide download service for the 
man on the street. 


One more thing 


When scaling a software organization through 
servitization, the software architecture has to be 


adapted. 


The chapter First things first describes a canvas 
that was created for this purpose, as a guide on how 
to improve the software’s internal structure. 


It is furthermore strongly recommended to work in 
an Agile way. Find canvases for Agile development 
in the chapters Pump up the volume, Deliver 24/7 
and Agile and Disciplined. 


Husqvarna is а global manufacturer of lawn and garden equipment, offering products varying 
from chainsaws to lawn mowers. They are now in a shift from offering mechanical products to 
also produce products having electronics and software. An increasing amount of unique product 
features now builds on software. The shift started in the mid 1990's when the first robotic lawn 
mowers were launched, but until 2016 the products had virtually no connectivity. It's connectivity 
that makes the machines able to communicate and possible to integrate with customer services. 
Husqvarna Fleet Services is such a service. 


The hardware of the system consists of a sensor that is mounted on the machine, an operator 
tag that is carried by the person who uses the machine and a base station that is placed in the 
customer's garage. The sensor collects data about how the machine is used out on the field. It 
also keeps track of who 15 operating the machine. When the machine is back in the garage, the 
data is collected and sent through a gateway to Husqvarna Fleet Services cloud data services. 
Operators, managets and technicians at the companies that subscribe to the service can then get 
information such as vibration levels, service needs and machine usage based on collected data 
that has been fused with data from other Husqvarna data sources. 


Husqvarna Fleet Services started in 2007 as an idea in the After-sales department, basically to f 
offer a service that help Commercial Lawn and Garden customers managing their fleet of Husq- Customer 
varna products. Until 2011, all development was run by After-sales as a study on a very limited expectation® 


budget. To create the proof-of-concept, they cooperated with an external technology company. = 
From that point, in 2011, the project gained increasing support from the R&D department. In | 
August 2014, a beta version of the service was finally released to a limited set of customers. А 
new R&D department was started in December, with the responsibility to host all Husqvarna 


service products, one of them being the Husqvarna Fleet Setvices. А group wide decision forum Gainin 
for product connectivity and a department for marketing and sales was as well created. The first S 
NE A : 2 anta 

limited commercial release of Husqvarna Fleet Services was released mid-2016. a 


Husqvarna’s products were becoming smart devices — but this wasn't enough: Husqvarna’s 
organization had to become smarter, too. As a hardware-oriented company, Husqvarna had 
initially very limited software and system development capabilities. An important step was to 
form an R&D department that could develop new services. The IT organization had to create a 
new department as well, with responsibility to build and operate the IT infrastructure needed for 
the service. They worked independently from the original parts of the IT department. The IT 
organization had to work in a Bi-modal way, so to say in one speed for the original IT work and 
in another speed for the rapidly moving services developed by the DevOps teams. 


Husqvarna saw the demand from the market, the need for a product like Husqvarna Fleet Ser- 
vice. They identified a market trend such as digitalization and Internet of Things and now the 
organization is changing accordingly. What originally started as an experiment is now reshaping 
the identity of the entire company — it's a transformation from a traditional, product-oriented 
manufacturing business to a business where services lead the way towards the future. It has taken 
a long time to get where they are now, about nine years. But the idea of introducing services was 
а good one, an idea that eventually made the whole company line up and work towards а com- 
mon goal. As this is written Husqvarna is still on the journey, but its chances to succeed in its 
servitization is considered very good. 


Customer expectations 


No R&D organization 
for services 


No sales organization for 
selling services 


No IT infrastructure 
for handling connected 
services 


Limited software and 
system development 
capabilities 


Hardware oriented com- 
pany. No connectivity in 
products 


Activity 1 


Activity 2 


Activity 3 


Activity 4 


Activity 5 


Gaining competitive advantage 


R&D organization formed 


Marketing and sales 
organizations for 

service products 

Group wide decision fo- 
rum for product connec- 
tivity 

Common IT department 
for connected services 


Agile DevOps process 
implemented 


Scalable and flexible com- 
mon back-end 


Connectivity built into 
products 


Services is 
a profitable rev- 
enue stream 


Services are 
offered for all 
products 
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This case study is about how the mobile phone manufacturer Sony Ericsson went from only 
offering physical products to also include a music listening service called “PlayNow plus". Sony 
Ericsson released their first Walkman phone in 2005. It was the world's first phone aimed for 
listening to music. The PlayNow plus service was basically introduced to increase sales of mobile 
phones, but also to be a step to keep the lead in the global music listening business. The service 
didn't have to be profitable on its own. 


The case study confirms that the culture, the understanding of how to sell the service, and how 
new ways of wotking are defined are the three most common challenges when introducing ser- 
vices. Atos Consulting* also confirmed these findings. The transformation requires several steps, 
including adjustment of KPIs, redesigning processes, aligning management, organization (not 
least the IT department), people, and culture. It is virtually impossible to shift the entire organi- 
zation at once. The servitization transformation is a journey and not a one-time change. 


Sony Ericsson was a product company with very little experience in delivering services. The 
service organization experienced huge difficulties in both changing the culture of Sony Erics- 
son as educating personnel in what it meant to deliver a service. Part of the explanation is that 
almost all sales came from selling mobile phones; no profit was expected from the PlayNow 
plus. Sony Ericsson continued to focus on product development and also expected the PlayNow 
team to align with their long-lasting product development cycles. With customers expecting new 
functionality continuously, the way the service developed and how it was operated was far from 
optimal. 


The IT organization did not have any prior experience of external customer facing applications. 
Due to security reasons, the service had to be hosted behind the company firewalls. The IT organi- 
zation simply didn't understand the implications of this decision. This led to enormous problems, 


¥ Atos 2011, www.consultancy.nl 


such as having to shut down the service during weekends during the regular maintenance of the 
internal IT systems. A service like PlayNow plus must be available 99.9% of the time, if its users 
should even think about using the service as their main way to listen to music. 


While cultural problems were among of the biggest internal hurdles to overcome, communicating 
the service business model to potential customers became their biggest external problem. The 
service organization lacked basic knowledge about the market. Two questions they didn't ask were: 


* Was there a need for the service ot did the users want another kind of music service? 
* Did the users like the service or was there a need for updates and new functionality? 


The PlayNow plus service was launched to the Nordic countries in August 2008. As a reference, 
Spotify was launched shortly after, in October. PlayNow plus offered DRM free (without digital 
rights management) MP3 tracks, while Spotity offered a streaming service. They offered basically 
the same service, but in two completely different ways. 


Spotify reported a loss of $4.4 million in 2008. But, as it had a long-term goal to be profitable, 

it could take the loss for an extended amount of time. PlayNow plus was never considered to 
be a future profit maker, nor was it seen as an investment. The service was terminated in 2010, 
as a decision to cut costs. 
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During the 1990s, а numbet of lightweight software development methods evolved in 
reaction to the prevailing waterfall software development methods. They all follow the 
principles that were outlined in the Agile manifesto 2001.* There are many agile devel- 
opment methods now. Most of them promote teamwotk, collaboration, and process 
adaptability throughout the product development life cycle. 


Agile development methods break product development work into 
small increments allowing frequent feedback on value and quality. 


Scaling Agile is a concept that helps you spread and consolidate the agile philosophy 
throughout the organization to follow the Agile Manifesto that says that “our highest 
btiotity is to satisfy the customer through early and continuous delivery of valuable 
software." 


This type of change is often very thorough and includes a review of leadership, gov- 
ernance and decision-making structures as well as the changing roles and modified or- 
ganization. The choice depends on the company's drivers — value creation, efficiency, 
innovation, or something else. 


Ж http://agilemanifesto.org/ 
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Companies that succeed with the scaling Agile 
process are characterized by three things: 


Co-located, cross-functional teams 


The teams contain all the necessary competence to deliver value, for instance 
developers, testers, architects and business representatives. The teams are as well 
co-located to get efficient face-to-face communication. 


Delegative style leadership 


Management must understand the agile values and make it necessary to imple- 
ment the planned change. Agile methods also requires that the leadership focus 
on teams in a very different way than the traditional command and control style. 
A more delegative and cooperative leadership style is needed. 


Iterative approach with short feedback loops 


Technology and infrastructure will enable fast feedback and fast, frequent release 
cycles. At the end of each iteration, stakeholders as well as customers review the 
progress and re-evaluate priorities to optimize the return on investment and to 
ensure alignment with customer needs. 


Scaling agile 
Pd Many large companies struggle with timely delivery of products and 
tomer Value Dir. services that customers really want. While agile methods are widely 
Pd "'TD ton ^ adopted, a key challenge is to scale the agil h to th 
pted, a key challenge is to scale the agile approach to the corporate 
level. While software development teams may follow agile methods such 


nn _ — as Scrum, customers may not benefit if other key parts of the organiza- 
A tion are still operating based on a watetfall philosophy. Adoption of Lean Thinking 
and Enterprise Agile philosophies that focus on end-to-end systems thinking 15 still 
Innovation limited, and the software industry has a long way to go to achieve the true benefits 


of being agile. 
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There are three reasons why a company 


Value stream 
would want to scale up agile to the whole 


otganization: 


1. Doing the right thing 
at the right time, 


Ер 
ee О ) ) ) ) 2. Focusing on delivering value to 
= the customer, and 


3. Improving the capability to innovate. 


0) ) ) ) ) Everything is sprung out of the need to 
become stronger, to innovate better products 


and to better differentiate between products. 


The scaling objective (what we want to become) is in the theory 
called Scaled Agile. Scaling Agile is the transformation that gets 
us there, towards the Scaled Agile. There is no actual end state, 
since the market, technical trends and so on vary over time. 


In this scenario we deal with two levels of scaling objectives. The primary objective 1$ to scale the 
value stream — this is what being Agile is all about, to take full responsibility from idea to payment, 
i.e. to have a working end-to-end flow within the organization. The secondary objective is to scale 
the offering — this is to scale stand-alone products or services. Each offering will have its own value 
stream and perform as a “mini-company” in its own. 
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It’s a challenge to get everybody on-board, getting everybody to accept full responsibility. Every 
person in the development process needs to understand the business, how the market evolves, and 
what competitors are up to. From what they know, they have to create a Minimum Viable product 
(MVP). This is a central concept in agile and lean philosophies, to not implement too little, not 
too much, but just about what is takes to keep the customer ahead and the competition behind. 
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Once a company has established an agile value stream, it becomes easier to differentiate between 
various products and services. Of course, it’s not as simple as just replicating teams, or worse, as- 
signing the same team for several product offerings. Scaling in the product domain, creating new 
products and services based on existing assets, usually means that the software architecture and 
supporting systems have to be adapted. Introducing continuous portfolio planning and project 
visualization will become of utmost importance to remain agile. 


Delivering continuously 《AR 


As innovation and coding can be dealt with by introducing agile methods, so can test, integration, 
build, and delivery practices. How about eliminating all manual work, developing an ability to de- 
liver a change to the customer within hours, or even minutes? How about being able to deliver bug 
fixes soon after they are reported, without causing any downtime in development? The solution to 
this is Continuous Delivery. Its practice is rapidly becoming very popular among major software 
and service suppliers such as Microsoft, Ebay, Amazon, Facebook, and Google. In particular prod- 
ucts that are deployed through the cloud are very amenable to this approach. 


Continuous Delivery helps in becoming more receptive and responsive to customers’ needs. To 
continuously get new features might not be what every customer wish, but many would even love 
to get early access to semi-finished functionality, to get a chance to give feedback while features are 
still in development. Feature toggles, to enable unfinished features, are for this purpose a very im- 
portant concept within Continuous Delivery. Another important concept is to implement essential 
features in two vatiants and using A/B testing to determine which variant wotks best. 
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Acceptance tests 


Continuous Delivery depends on a delivery pipeline — a series of steps that a product’s source code 
has to go through to be delivered. To establish such a pipeline isn’t trivial and doesn’t happen over 
a night. Apart from the very challenging task to automate delivery to customers, the biggest chal- 
lenge is to automate testing. Constructing a comprehensive test suite that is good enough takes a 
lot of time, and so does the implementation of the required automation tool support, which is an 
instrumental and challenging part for any organization. To continuously allow all changes that pass 
all tests to be deployed to customers requires a mature and stable team that embraces a culture of 
confidence, humility, and capability. Everything boils down to sound management, to encourage 
an altruistic mindset and culture, and to build the trust that is needed for such a culture. 
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Maintaining stability 

When scaling IT systems in an established company, there is usually a need to balance the stability 
in legacy systems with the flexibility in their agile, bleeding edge offering, The work with core tech- 
nologies and infrastructure 1s deliberate, consensus-driven, and slow moving, and so it has to be. 
The cash cow must not be rushed. The most novel products and services, on the other hand, may 
be highly experimental and may require more frequent updates in the technology infrastructure. 


Innovation intense systems 


Exploratory 


Differentiating systems 


Traditional 
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Core systems 


This is called Bimodal IT, the concept of having two distinct IT methodologies in the same 
company. The Agile IT team handles the growing needs of the business while the core IT team 
handles day-to-day business technology functions. The Agile IT team can quickly roll out fast 
evolving technologies while the core IT team executes long-term plans and goals in a more disci- 
plined fashion. 
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Keeping the IT systems separated but balanced can be a deliberate and strategic decision. Busi- 
nesses that have outsourced application development might also want to keep their core IT infra- 
structure stable in order to keep control of software deliveries from their external partners, who 
wotk following agile principles. 


Despite the neat separation implied by Bimodal IT, the different teams will need to cooperate. 
The Agile IT team is still dependent on back office applications provided by the core IT team. 
Both teams have to respect the different ways of working and agree on mutual processes. How- 
ever, to avoid getting the teams too intertwined, it's good to create a layered or modularized base 
system architecture to from the beginning that provides and suppotts a high degree of change 
and agility above it. 


Keeping two separate IT teams can prove to be a challenge. In order to create a bridge and to be 
able to btiotitize between conflicting interests, it's recommended to have a CIO managing them. 


Senior managers often believe they fully understand and embrace agile principles, yet they 
demonstrate the opposite when making decisions. Situations like this can be difficult to rec- 
ognize and mend whilst the managers in matter have attended training sessions and use the right 
agile buzzwotds. It's not that they're faking it; they honestly believe they're doing the right things. 
So what can we do? Experience has shown that having more workshops, training, and discussions 
are not the most effective approach. A better way to tackle this situation is to let the management 
team visit another company for in-depth demonstrations and sharing sessions, and to introduce 
them to agile champions and leaders that can demonstrate what agile leadership really is about. 


Low maturity in a company's continuous integration and test procedures causes long 
quality feedback cycles. To have successfully implemented procedures include at least daily 
integration and build, and some level of automatic testing. If the environment and processes 
don't allow for this, then further steps in the agile transformation journey have to focus on this. 
Its sometimes difficult to identify who should dtive this change. There are many stakeholders, 
including production, legacy system owners, and quality assurance, and this makes running change 
activities difficult. 


Administrative matters such as organizational structures, governance, forums and roles 
get more attention than the focus on achieving agility. If development teams aren't agile, 
then we're scaling something that doesn't work. This causes unnecessary overhead in terms of 
coordination between teams and micro management of the whole program. So, make sure that 
development teams work well, that they have product owners, use a backlog and have a clear defi- 
nition-of-done. Ensure they are self-organizing and have the authority and skills to pull, plan and 
deliver their work and to get frequent feedback. 


Distributed development and dealing with multiple vendors are challenging. Fundamental 
aspects of agile methods include a team's ability to self-organize, transparent collaboration, and 
quick feedback cycles. Geographical distance and cultural differences combined with multiple 
vendors and diverse business and contract models require a lot of the development organization. 
It's necessary to share visions, high-level goals and agreed-on deliveries between the different or- 
ganizations, to maintain total visibility. Organizational boundaries have to be removed to get fully 
cross-functional teams. If you really need to engage multiple vendors, you also need a well-crafted 
outsourcing strategy that works with multiple suppliers. 


Stick to old ways for governing projects with demanding progress reporting hampets agility. 
With traditional governance — involving steering groups and traditional portfolio management — 
projects are burdened with detailed estimates in terms of investments and return, milestones and 
decision gates, and expected dates for deliveries. All results are basically a product of a project with 
all people and budget allocated in advance. Any deviation is managed 


by renegotiating project scope and budget, resulting in people get- 
ting shuffled between projects. When working truly agile, there are 
no projects with allocated people. Instead, there are a number 
of backlogs and a total development capacity. The developers 
otganize themselves in teams that pull prioritized work out 
of these backlogs. All planning and governance is based 
on a quarterly, monthly, and weekly cadence. There are 
still people responsible for the business. They decide 
what and when to release. From a management point 
of view, this regime requires a lot of trust. It's im- 
portant that there is full transparency to how 
much the teams can deliver рег delivery. This 
enables product owners to make forecasts 
and reprioritize the next delivery. 
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Get inspired 

This scenario has been based on case studies of different companies that have made this 
journey, to scale with Agile. Learn from their experiences, what they gained and what they 
had to overcome. 


=) Pruning a bush 
—1 At this company, any development of new functionality literally drowned in the work to 
support customers and fix bugs. Read about how they implemented SCRUM and Kanban 
without jeopardizing the relations with their customers and quality in their old products. 


ES Ensuring prima deliveries 


Critical bugs passed unnoticed for weeks or even months. Corrected bugs took days or 
weeks to deliver, since the procedure is manual and requires the system to be shut down 
This was the situation when a team at Prima decided to implement Continuous Delivery. 
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the larger customets desired to have the products branded as theirs. The consequence was а 
complex branching strategy (a way to keep track of the software for each customer). Every bug 
needed to be fixed and tested in all of those branches. This made the releases very difficult. The 
many branches made it impossible to keep their release deadlines. 


The company had long release cycles due to their lack of capacity but mostly because their N 
customers do not want changes too often. Many products in the field never even got updated, 

products that the company’s technicians needed to be able to maintain and service. A few of 

Any development of new functionality literally N 
drowned in the work to support customers and 

to fix bugs. The development department was 

drenched in work and very little new software 


to move all patches from the release branch to 


was produced. However, a new product was 
in the roadmap. The organization knew they 
needed to make this a priority without jeopar- 


the main branch. Sometimes there were several 
release branches to merge into the main branch. 


m : : | It was а mess. 
dizing the relations with their customers and 


quality in their old products. 


The maintenance team added the patches directly on the customer's production branch at any 
time. So when a new release was created, all patches from the different customer branches had 


to be added to this release. The many and often conflicting patches made integration and veri- 
fication very difficult. Having released, the team then had to move all patches from the release 
branch to the main branch. Sometimes there were even several release branches to merge into 
the main branch. It was a mess. 


The Agile transformation started by training the development teams, product owners and man- 
agers in Agile, Scrum and Kanban methodologies*. After the training was completed, new ways 
of working were introduced in a big bang. The department was divided into three development 
teams. The team that got responsibility for maintenance started to work according to Kanban. 
The team that got to work with customer projects and the team that got to work with new prod- 
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ucts started to work according to Scrum. The people in the test team were all distributed in the 
agile teams. 'They were assigned to write user stories, define acceptance criteria and also to train 
the developers in how to test. The testers could now focus on more complex test cases and the 
overall quality. 


External coaches facilitated the first sprint. The responsibility was then handed over to the 
team's Scrum masters and Kanban leaders. The two development teams adapted quickly and 
started to produce and solve challenges as they arose. The external coaches were still available, 
to support the teams, the scrum master and the managers in their new roles. They also got help 
with their group development, to help them in seeing how to improve. The branching strategy 
was changed after a thorough analysis. Now, all bug fixes and new functionality had to be tested 
and merged into the main branch after every sprint. 


As the maintenance team started to work with smaller batches of bug fixes, they could as well 
take the step and merge corrections both into the service pack release branch and the main 
branch. Integration and verification of every batch went so much faster. They could in this way 
guarantee the quality on both branches. 


It turned out to be very important to not exceed 10 bug fixes in a batch. Twice, the tried to 
include 20 bug fixes. But after having discussed the effects in retrospective, they concluded they 
ought to stick to 10. With 20 bug fixes, it simply took too long time to do the integration and 
verification. By sticking to 10, the releases could be finished on deadline and without any over- 
time. They hadn't been able to do this for a very long time, a huge step forward according both 
to management and the employees. 


To get the software departments up and running with Scrum and Kanban required two weeks of 
initial training. 
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Many organizations are suffering from sub-optimal development and deployment process- 

es. Common bottlenecks are: outdated tools, lack of systematic and pro-active error handling 
procedures, and deployments that only can be made at night time in order to limit downtime. 
The consequences are low quality and delayed deliveries. The feedback loop from customers to 
developers tends to be too long, Critical defects can pass unnoticed for weeks or even months. 
With manual deployment procedures that require a system to go offline, defect fixes might take 
days or weeks to deploy. 


This was also the situation when the Swedish company Projekstyrning Prima (Pti- 
ma) decided to implement Continuous Delivery of its route planning systems. To 
that end, Prima developers introduced new systems for source control manage- 
ment, build automation, automated deliveries, and a new way to log information 
— one module and one developer at a time. These steps made a great difference 
to their productivity, their lead times to correct bugs and their confidence in their 
products. It was no longer necessaty to take systems offline for an update, or to 
wotk long nights ot weekends. With this set of tactical changes, new product 
versions could be deployed in the middle of the day, without any downtime. The 
resulting shorter cycles and faster deliveries of both features and defect fixes led 
to increased customer satisfaction and fewer calls to Prima's support lines. The 
shorter cycles also made it easier to plan the work ahead on a realistic time scale, 
and measute effects such as product quality of their new approach. 


The key driver for Prima was to increase the release cadence without jeopardizing the quality and 
stability of the product. To make this possible, the development pipeline had to be fully auto- 
mated, which itself required some significant updates of their existing tool chain. 


Prima was using the Microsoft Azure cloud platform, but this wasn't a key problem. The chal- 
lenges they ran into could have atisen with any cloud technology stack. While cloud technology 
certainly facilitates a transformation to continuous delivery, this wasn't a key requirement. 


The changes that the Prima team made took just over three weeks — less than 16 days to be 
precise. Some of the major improvements were made by rethinking and simplifying the product 
release procedures. Another cornerstone for making improvements was to introduce monitoring 
systems: detecting when things go wrong is essential to continuously improving processes and 
removing bottlenecks. This continuous improvement is key in true enterprise agility and can also 
be traced back to the Lean Thinking philosophy. Continuous improvement is not the destina- 
tion—it is the journey itself. 


28 f Se 


Lean Thinking is derived from the Toyota production System, which itself contains many con- 
cepts using Japanese words. One simple tactic is described by “Genchi Genbutsu”, which refers 
to the simple act of going to the production floor to see “what’s going on.” By simply letting a 
coach walk through the steps with every member of the team helps to overcome many prob- 
lems. Soon it became clear that the chance to succeed increases if everybody knows the whole 
team, and the product, before embarking on this journey. Of course, using support from mod- 
ern tool chains is a necessity. These tools don’t need to be very expensive—many of the tool 
chains are available free of charge as open source products. While some tool migrations might 
take some effort, such as migrating to a modern source code management system, such invest- 
ments will pay off in the end. This is one of the many trade-offs that teams will have to make in 
a process improvement initiative. 
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When scaling a business in terms of efficiency, all that matters is how to build the products 
faster, more predictable and in bigger volumes. Innovation is not a matter at this point. This is 
а business need that mostly appears in very large companies that deliver complex products ог 
services to the market. They search for ways to be more productive together in an organization 
that suffers from too many dependencies between products, services and departments. This 


complexity makes the offering sensitive to changes and the organization likely spends significant 
resources on maintenance. What complicates everything is that the scaling would need to be 
made without serious interrupts in the product development. This is where scaling Agile comes 
in, an approach cut out for the change. 


Agile development, for example Scrum and Kanban*, has rapidly proven to be the preferred 
methodologies among software teams and their developers. Even if a company formally hasn't 
made the switch to use Agile methods, it's not unlikely that some of their teams already have 
started to work this way. Teams working in an Agile fashion strive for clear goals and boundaties, 
open communication with full visibility of decisions and priorities. 


Letting go of details and focusing on Lean and Agile principles will turn out to be challenging 
for most managers in a traditional organization, even if it's been successfully proven empirically. 
They have to be courageous and trust in the method and in the staff they manage. In fact, Agile 
provides discipline, transparency and working code frequently so trust will come by itself. It's 
important to grasp the idea that scaling Agile has no end; this is the way the organization is run. 


Organizations that have been scaled in this way shows that they are able to deliver utterly com- 
plex products and services with remarkable efficiency. There are of course pitfalls ahead, when 
focusing on efficiency over a too long period of time. While being reactive is considered good in 
Agile, it’s important to consider all customer requests carefully. The product owner has to make 
the right priorities. It's important to not forget to start innovate again. 
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| а . There are several frameworks for scaling Agile and there is no right or wrong 

| choice. A decision of what combination of frameworks to use can be made once 
Implement Agile there is an agreement of what is relevant to the organization. If you already use 
ruis Scrum in the company, you might want to consider LeSS (Large-Scale Scrum). 

— . — LeSSis sprung out of complex R&D development and emphasizes on contin- 
uous learning, inspection and adaption of both product and processes from a systemic point of 
view. If portfolio and program level management is central to your company, you might want to 
get a closer look at SAFe (Scaled Agile Framework*). SAFe put emphasis on governance, pro- 
gram and portfolio management and in particular suitable for organizations from hundreds to 
thousands of developers. 


Ж www.scaledagileframework.com 
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All frameworks have their differences but they all share the Agile principles. This means also that 
the change will require new roles and ways-of-working, even in an organization that uses Agile 
development methods. It’s a good idea to form a cross-functional change team. To change the 
mindset of leadership and the governance will be one of the biggest challenges in this trans- 
formation. One of the most important principles of Agile software development is to have 


self-managed co-located cross-functional teams working. The teams should understand the re- 
quirements fully and have all necessary competence to take all decisions for the functionality that 
they ate tesponsible for. Read more about change in Your journey. 
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Another important aspect is to have close cooperation between the product management and 
the development team. Ideally product management competence must be in the self-managed 
teams, so that the communication is fast and direct. But there are some Agile frameworks that 
promote to have the product management in a central team. Whichever way this is organized 
communication needs to be daily. Teams need to regularly reflect on how to become more effi- 
cient. This should ideally be done regularly. 


Follow up on progtess in software-based projects is usually a big challenge. In an Agile project 
the progress is measured by code that is actually working (according to the definition of Done). 
Since functionality is split up in smaller pieces (chunks), this is a proven way to measure prog- 
ress. This also drives customer satisfaction, due to that customers can give their feedback in eatly 


phases of the development cycle instead of at the end of a project. Customers usually want 
specific features while engineers like complicated implementations that cover everything. This is 
why emphasis 15 put on choosing the simplest possible solution. It makes customers happy and 
engaged already in the early phases of the software development lifecycle. 
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This scenario has been based on case studies of different companies that have made this 


journey, to scale with Agile. Learn from their experiences, what they gained and what they 
had to overcome. 


ES Global R&D goes agile with SAFe 
N This study from Ericsson brings up the difficulties in implementing GoAgile with SAFe in a 
global organization. 


ES Multi-site development 


^ If you're into services, you might want to read about how the large mobile operator gained 
excellent predictability by visualization. 
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The global high tech company had struggled for quite some time to deliver as promised. This 
had created a strained relationship between the company and their customers, which seldom 
believed in the promised dates and the quality of the deliveries. When the customers got back 

to the company they had to wait far too long to get corrections. The market competition was at 
the time getting tougher and tougher for the company. Many competitors aspired to be the rising 
star. The company had to realize that they have to be much more efficient. They had to make the 
most out of their employees to speed up development and to solve customer feedback cases. 


These drivers initiated their Agile transformation: 
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The first ideas of how to structure the organization were formulated in 2012. The focus was on 
speed and how to fight competition from other platform providers. The transformation journey 
started in mid 2013, by the creation of an organization that would fulfill the demands from the 
current mobile platform market. 


The organization was set up as an R&D organization parted in four requirement areas (RA) and 
one integration & verification organization. Each RA was responsible for either a technology 
atea (like core SW) or a function area (like test). These RAs were located to 4 different sites over 
the world; in fact, the same RA could even be distributed over several different sites. About 800 
people in Sweden and about 1500 persons globally were affected by the transformation. The 
change was led by a core team working in an Agile way, using whiteboards and visualization. 
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The R&D organization improved well, both the integration time and the customer response time 
decreased. A major reason this went so well was that the introduction of Continuous Integration 
and Continuous Delivery. Read about this in the chapter Deliver 24/7. Another reason was the 
coaches, who worked with the teams to help improve transparency and collaboration. A stable 
change velocity helped the product management to make releases predictable. Realizing that 
more and more Agile tools actually worked, they completely changed their mindset. А year after 
the start of the transformation, the company was able to manage a full program increment, an 
activity that last over a quarter of a year. At this point in time, everybody in the organization 
could go to the visualization room and have a look at the different RA plans, goals and KPIs. 
Everything was updated on a regular basis. 


The biggest challenge in the transformation was to change the mindset in the organization. 
Slowly, small success stories spread in the company, making people to start trust one another. А 
cultural change like this takes a long time and needs to be given sufficient focus. 
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The management of a large mobile operator had realized that one of their biggest projects was not 
progressing at all. The project had been planned as always, in accordance with waterfall principles. 
All specifications had been created and yet no one knew how to start. With lots of money and 
prestige already invested in the project, it simply had to succeed. 


The project aimed to merge a multitude of different systems, of different age and status, into one 
big system. Part of the development was made in-house, but part were also made by many vendors 
spread over the world. 


In their current system, it was difficult to find knowledge about their customers. The information 
was spread out оуег different systems and customer service needed to access all these systems to 
support their customers. But, the work took a long time and it was hard to train them. The system 
was practically impossible to work with. It was particularly difficult to create bundled products 
across different channels. The tools needed existed, but resided in systems that were not connect- 
ed. They desired to create a cohesive experience across all channels. It should look and feel the 
same on all platforms. 


They finally understood that such a massive and complex project could not be thoroughly planned 
from the start to the end. A clear goal had to be set and the solution had to develop over time, 
with tight learning and feedback cycles. That's when they decided to start wotking with an Agile 
methodology. 


First they implemented Scrum as a project methodology. They divided the large in-house team 
into two smaller teams, to keep the team members focused. A single, prioritized backlog was cre- 
ated and the teams started to develop based on it. This change alone turned out to be one of the 
most important ones they ever made in the project. During the following six months, an extensive 
recruiting took place. In the end, five teams worked side by side on the same project. 


But one challenge remained. They didn't manage to solve the long lead times that were required 
for each new function they added. The many dependencies between teams and vendors made it 
very difficult and many functions had to be iterated a few times before they worked. Velocity, by 
which each team was measuted, turned out to be useless as a mean to estimate the releases. Depen- 
dencies were handled during the refinement of a task, by pre-order from the team that depended 
on certain functionality. When a task was developed based on the specifications, it often had to be 
redone. The team that ordered the functionality in the first place would then often find something 
that needed to be changed, and place a new pre-order. 


To have any chance to succeed, they needed to reduce the lead time and the significant amount of 
ongoing work. The change team concluded in that Scrum had to be replaced by Kanban, in each 
team and on a project level. Work-in-progress limits is the key principle in Kanban. Additionally, 
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a limit was set of how much ongoing work was allowed at the same time. On project level, a Kan- 
ban board was introduced. It gave an overview of the features each team was working on. A clear 
"definition of done" was also defined between each team. The project management could now 
use this board and start estimate throughput and lead times on an overall level. They had real data 
to analyze in otder to see if the project was going to manage the project deadline. They could now 


re-prioritize based on this information. Each team and vendor got such a Kanban board, enabling 
them to prioritize tasks and solve their bottlenecks. They also introduced collaborative analysis and 
design, in which key people from each team met and talk through each task, what the task means 
to them. 


А key get-away from the project was the importance of visualizing work in progress on both proj- 
ect and team level, to make sure problems are detected fast. They solved it by start using JIRA* in 
the cloud, by this enabling smooth access by both external and in-house teams. 


To split the original organization into two teams and start running Scrum took a couple of weeks. 
It then took almost six months to expand to five teams and another six months to become aware 
that the set up was not working. The resulting move from Scrum to Kanban, to get all teams 
and vendors on boatd and get everyone involved in the collaborative meetings, took another six 
months. 


А key motivation for the change was to make their very large project finish before deadline. They 
desired to be able to predict what patt of the scope could be completed by that time. By being able 
to do this, they could then re-prioritize early and solve problems as they appeared. 
Did they deliver in time? Yes, they did. 
Ж A bug tracking, issue tracking 
and project management tool 


Quality 


Long lead 
times 


Quality not 
sufficient 


Problem with 
visibility in proj- 
ect follow up 


A lot of time is lost on coordination 
because teams are not able to take 
decisions on their own 


Very little cooperation 
between development and 
product management 


Requirements are not always un- 
derstood by the developers 


Plans are not followed up 


Customers frequently 
dissatisfied with the 
outcome 


Productivity 


Project predictability 


Close, daily cooperation between busi- 
ness people and developers where plans 
are adapted to current situation 


Increased 


Regularly, the team reflects on how| quality 


to become more effective and adjust 
accordingly 
Co-located self-managed 
teams with prioritized backlogs 
of requirements 


Implement Agile work-flow 


Working software is the 
principal measure of 
progress 


Customer satisfaction by 
early and continuous deliv- 
ery of software 


Implementing the simple 
solution 


New architecture that sup- 
ports agile way of working 


Increased 
productivity 


Software 
organization 
deliveries are 
predictable 


SCENARIO / 


С There is no room for bugs 
and maintenance updates 
when life is at stake 9 9 


Some businesses imply 
severe demands on design 
and manufacturing. 


Take a car maker, 
or a manufacturer of dialysis machines. A 
software bug in their products could have seri- 
ous consequences on public or personal safety. 
Rigorous safety and quality norms have to be 
met by these products and services to reduce 


risks to acceptable levels. 


Regulated domains, such as automotive and healthcare, are compliance oriented. Products and 
services need to adhere to domains-specific standards, and so does the process of developing, 
manufactuting and deploying those products and services. Consider the automotive domain, 
for example. A cat contains parts and components from thousands of suppliers. In Europe, the 
Original Equipment Manufacturer (OEM) takes full responsibility for the product and has to be 
certain that all the parts from its suppliers ate compatible in performance, durability, and many 
other qualities attributes. All parts need to be engineered and produced according to stringent 
quality standards. Quality standards are not enough, though. Additional requirements such as 
safety and security have also been deployed as standards. 


Many regulatory requirements seem to conflict with Agile software development principles. For 
example, the Agile Manifesto values working software over documentation— yet, it is documen- 
tation (e.g. for process traceability) that is so important in regulated domains. Therefore, it's still a 
challenge to apply Agile development methods within these domains. 
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Drivers 


Agile methods have seen widespread adoption in the software industry with some surveys sug- 
gestion adoption rates of up to 80%, and for good reasons. The iterative, time-boxed approach 
with regular feedback cycles helps to improve software quality and customer satisfaction, and to 
improve developer productivity. Many of the drawbacks of traditional waterfall-based approach- 
es can be overcome with Agile methods. However, Agile methods were initially seen as inappro- 
priate for use in regulated domains such as the automotive industry and medical devices. 
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In the last few years, driven by market demands and companies' desire to improve their devel- 
opment processes, this assumption has been challenged, and companies in various regulated 
domains have exploted how to adopt — and adapt — Agile methods for their specific business do- 
main. 'This is also driven by trends such as digitalization in society and Internet of Things. While 
safety requirements are still of primary concern, even companies in these regulated domains 
need to consider the increasing demand for new and innovative software. 


So, the drivers that have led many companies to adopt Agile development methods also 
play an important role in companies that ate subject to regulations and standards. 
They hope to achieve benefits such as quality improvements, cost reduction, and 


shorter time-to-market. But they also have to get better in communicating 
with the consumer. The digitalization trend that sweeps through our in- 
dustry, and society at large, is changing customers’ expectations. Cus- 
tomers now expect to interact with devices through web-based in- 
terfaces, and seamless interconnectivity between different devices. 


Companies in regulated domains have traditionally been us- 
ing waterfall-based development approaches, including the 
“V-model,” an extension of the waterfall model, but many 
are now moving towards agile methods. However, while 
adoption of methods always requires tailoring to a specific 
development context, regulated domains require a number 

of specific considerations. 


A number of general factors affect how a company should 
tailor agile methods. Some of those factors are: 


* How many that work with the software 


* Whether or not software is developed by distributed teams, 
and if so, how many locations are involved 


* Whether ot not patts of the development ate outsourced 
* Experiences of the workforce and organizational culture 


* Complexity of the product and whether ог not it concerns embed- 
ded software that runs on specific-purpose hardware 


* "Greenfield" development (start on a clean slate) versus “brownfield” de- 
velopment (continue develop on existing software) 


* Criticality of the software — whether or not the software must comply with standards 
and regulations 


In regulatory businesses, a product has to be proven to be safe. To this end, a company can create 
a Safety Case, which consist of structured arguments supported by evidence that the sys- 
tem 15 acceptably safe for a specific application in a specific operating environment. 


There are essentially five principles that summarizes safety requirements Юг 
software: 


* They shall be satisfied 

* They shall be maintained throughout requirement decomposition 

* They shall address the software contribution to system hazards 

* Hazardous behavior of the software shall be identified and mitigated 
* The confidence shall be managed in relation to the system tisk 


In order to provide evidence to the safety case, a few areas need 
to be fulfilled although they are not strict agile ways of working: 


* Extensive product documentation 
* Full traceability from requirements to test cases 
* A documented way of working 
* A documented risk management process 
* Independent quality assurance 


All these areas have to be adhered to satisfy the safety standards. 
It's not regulated how these are satisfied, but traditionally this has 
been accomplished by using a waterfall development method, with a 

heavy verification and validation phase at the end. A short-term solu- 

tion of how to move away from waterfall development principles is to 

replace the heavy end of the project with verification and validation of re- 

leasable project increments, followed by a final but smooth validation at the end 

of the project. А long-term strategy requires the industry to change the standards 
in a more Agile direction. 
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There is a short-term strategy for any company in regulated environments that wants to work 
agile: Apply as many Agile ideas in the development organization as possible by still following 
the standards that needs to be fulfilled. You wouldn't get Agile by the book, but as Agile as possi- 
ble. By making the following adoptions, most companies can profit from the benefits that Agile 
software development has to offer. 


Architecture 
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The hardware architecture is traditionally reflected in the software architecture. This has some 
advantages, but also some disadvantages. It is worthwhile to split the architecture in two or mote 
parts, where some are connected to regulatory aspects and others are not. This makes it possible 
to also split the organization in the same way, enabling the parts that ate not affected by regulato- 
ry requirements to work in a more Agile way. 


Autonomous teams 
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Introduce autonomous teams with full functional responsibility and by this reduce handovers 


and dependencies. Making decisions at the right place encourages furthermore commitment, 
engagement and minimizes changes and task switching. 


Working code, short development cycles and continuous integration 
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The development work can be done in an iterative way. Create a so-called minimum viable prod- 
uct in weekly or biweekly steps. Always having working code increases the overall quality of the 
software. 


Minimum of documentation and functionality 


Minimizing documentation and functionality is 
а good strategy to increase quality. Doing as 
little as possible to fulfill the requirements has 
proven to increase customer satisfaction. 


Quality and verification 


by agile means 


Visualized system and 


work in progress 


Itis also possible to adopt quality and verifi- 
cation requirements to Agile ideas. One way 
is to run daily, automatic regression tests. 


To visualize work in progress and technology 
is a core part of Agile ways of working. It 

is possible to also work like this in regulated 
projects. 


Customer needs 


It is of course possible to also focus on 
customer needs, perhaps the most critical 
agile principle. This is best done by early 
and continuous deliveries that can be shared 
with the customets. 


Improvements in small steps 


It's important to reflect and learn in 
small steps by for instance having 
weekly retrospectives. 


Customer value 


Better differentiation 


Feedback loops on 
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introduce new 
functionality to 
market 


Teams are organized 
around parts of the 
architecture rather than 
Productis only functionality 


partly connect- 


ed 
Quality not e" geit y 
e assurance activities 
sufficient 
Prem Waterfall development 
with visibility in 
project Low visibility of progress 
follow up 
ple ig Traditional architecture 
u following the hardware 
Great prob- Documentation is huge 


lems with late 
requirement 


changes Customer features are not 


taken care of 


Innovation 


Quality, cost, 
productivity and proj- 
ect predictability 
Time-to-market 


Reflecting and learning in small steps 


Feature oriented teams with 
full responsibility for end to end 
functionality 
Independent quality assurance 
adopted to agile ways of working 


Organization adopted to an architecture contain- 
ing regulated and non-regulated layers 


Agile development with 
continuous delivery 
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open 


Introduce a layered architecture 
to be able to work agile in parts of 
the software that have no regulato- 
ry dependencies 


Minimized documentation 


Focus on customer satisfaction by early and 
continuous delivery of functionality 


Get inspired 


This scenario has been based on case studies of different companies that have made this 
journey, to scale with Agile. Learn from their experiences, what they gained and what they 
had to ovetcome. 


Scaling Agile in Automotive 


Kugler-Maag are a key player who aim to bring innovations to the automotive sector, in- 
cluding the use of agile software development methods and open source software. 


Scaling Agile in Life Sciences 


Agile methods were originally considered unsuitable for regulated domains, but QUMAS 
found a way to scale the Scrum approach to be compliant with the standards and regula- 
tions in their domain. 


One more thing 


Scaling a software organization in the regulated do- 
main seldom means to only implement Agile ways 
of working. Many organizations have to redesign their 
software architecture. Continuous delivery usually 
gets a high rank in the wish list. The organizations also 
tend to see clear competitive advantages in adapting 
to service-oriented business models and to work in 
a network of co-creators that uses open source soft- 
ware. All these areas have been covered by other sce- 
narios in this book. 
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The automotive industry is going through a huge transformation. The entire industry has been 
disrupted by a connectivity trend. This case study is based on an industry survey conducted by 
Kugler Maag Cie,* a leading consulting company with many of the well-known car manufacturets 
as its customets. Over 40 expert interviews with decision-makers in the automotive, IT and tele- 
communications industries were combined with an online survey to find the main influences that 
affects software development. The conclusion represents the transformation that the automotive 
industry 15 in the middle of. 
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This study involved interviews with over 40 experts and decision-makers in the automotive, IT and 
telecommunications industries. A large-scale online survey was subsequently conducted to identify 
the key trends with respect to the role of software and its development in the automotive indus- 
try. The key finding 1s that, similar to many other domains, the automotive industry is currently 
experiencing a major transformation as the role of software is becoming increasingly important. 


Customers expect their cars to be web-enabled, with many advanced features that are now custom 
for smartphones. Cars get increasingly more features, and similar to trends found in the smart- 
phone industry, the car becomes a platform to which customers can seamlessly connect their 
peripheral devices. As a result, this increasing demand for new features and innovation delivered 
more quickly requires that the automotive industry responds more quickly. This is where the in- 
dustry hopes the promises of agile methods can be realized. Implementing agile practices such as 
continuous delivery is not without its challenges, but it doesn't have to be an impossible mission. 


The architecture is replaced by a layered and service-oriented architecture, containing a physical 
and a connected layer. This requires R&D to replace proptietary component-oriented product 
architectures with Internet enabling service architectures. The latter inevitable changes the R&D 


Ж See for the full report: www.softwaredrives.com 
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otganizations, mostly because the culture in the organizations performing the R&D tasks for these 
two layers will develop differently. They have to work in a Bimodal way by focusing on speed of 
innovation and inter-disciplinary cooperation at the connected layer and focusing on quality and 
safety at the physical layer. 


Also in automotive, development communities are expected to emerge dynamically around ser- 
vices. 


The car manufacturer needs to work with open standards to quickly adjust to different organiza- 
tional cultures of changing partners. In an agile organization, independent but networked units 
can quickly and flexibly be reconfigured, as the world changes. 


This is pethaps the most challenging part of the transformation, this that services become more 
important than products and only a small share of the profit is created through sales of physical 
products. The cultural challenges far outweigh the technological challenges. 


The Internet of Things phenomenon is a critical enabler to gain more sales through service based 
business models. The executive management must acquire the necessary core competence to har- 
ness the emergent power of this new technology. 


Once a car moves into its production phase, software development must carry on and add new 
functionality. Cars have to support updates and add-on apps that are developed after delivery. 
Naturally, the start of production-focused development has to be replaced by continuous devel- 
opment with short release cycles. By the architectural changes already mentioned, in combination 
with standardized hardware with performance resetves, the functionality of the cat can be expand- 
ed significantly. 


To enable fast return on investment, the organization needs to optimize the time to transit soft- 
ware changes to the field. It has to leverage from standards through a platform to get truly success- 
ful with continuous development, to enable additional revenue in the longer term. 


Open source software in vehicles is already a reality. Open source will also become widespread in 
functionally critical software. This will in turn affect the organizational structure of companies as 
well as the way of working. The transformation has not really an end state. 
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HB Standard Serum 
№ Regulated Serum (R-Serum), tailored specifically 
to the needs of regulated environments 


Agile methods have long been thought only to suit small projects with co-located teams that 
don't operate in regulated domains such as the automotive and medical sectors. This case study 
describes how QUMAS, a leading supplier of regulatory compliance management software to 
the life sciences sector has tailored the standard Scrum framewotk to regulated environments. 
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Increased sales Productivity 


Time-to-market 


QUMAS had employed a classic Waterfall approach ever since the company was founded. The 
approach resulted however in a long time-to-market and a large release overhead, all-in-all quite 
serious weaknesses on a rapidly changing market such as the one QUMAS operates in. To com- 
bat this, the company spent about two years to adopt and augment the Scrum methodology. 


The Agile Manifesto offers four value propositions: 


Individuals and interactions over Processes and tools 
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Working software over Comprehensive documentation 
Customer collaboration over Contract negotiation 


Responding to change over Following a plan 


While agile advocates accept that the blue statements on the right are important, they value the 
red statements on the left more. Howevet, in regulated environments, the blue statements on 
the right loom very large and are perceived to be key. If it isn't documented, it isn't done is a 
frequent refrain in the regulated domain. Agile methods may for that reason appear to be inap- 
propriate for regulated domains. They aren't, of course, but they need to be tweaked to fit the 
regulatoty requirements. 


The standard Scrum framework defines roles, ceremonies and artifacts. The product owner, 

the team, and the scrum master are for instance roles. The ceremonies include activities such as 
the daily stand-up, the sprint planning meeting, the sprint review and the retrospective meeting, 
Artifacts include the product backlog, the sprint backlog and at the end of every sprint, a “ship- 
pable" product. QUMAS's development process is regularly audited. In order to comply with the 
various regulations they are subject to, QUMAS has extended the standard Scrum framework 
with a number of additional roles, ceremonies and artifacts, resulting in R-Scrum: Scrum for 
Regulated domains. 


New roles New Ceremonies New Artifacts 


Quality Assurance 


Dev Check Marketing demo material 


User documentation QA Check Point Updated design documentation 


Hardening sprint Non-conformance report 


Quality Assurance is an important additional role in R-Scrum. Regulations require that QA is in- 
dependent from the development team. The QA Check Point is a new ceremony that takes place 
after every sprint, when QA conduct an internal audit to ensure “continuous compliance". Rath- 
er than conducting an extensive, annual audit, audits now take place after every sprint. Any issues 
that emerge duting the audit are reported in a non-conformance report, which is addressed in 
the next sprint. 


The user documentation role is also new and assigned to at least one member of the develop- 
ment team. The team has also got a new ceremony, the Dev Check. After a task is completed, 
any code and documentation is peer reviewed by another developer. This is required by the reg- 
ulations that QUMAS must adhere to. Another new ceremony, the hardening sprint, should be 
done just before the final release to ensure that the product is fully compliant with all necessaty 
regulations. 
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Traceability is a key concern in regulated domains. QUMAS have adopted the Atlassian toolset, 
which offers full end-to-end traceability. Jira is used for issue tracking and project management. 
Other tools in the toolset offer source code search, an enterprise wiki, agile planning and project 
management, continuous integration, and peer review. The toolset is a key ingredient to the Agile 
transformation and facilitates a very effective audit process. 
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Lessons Learned 


QUMAS have successfully tailored the standard Scrum framework to facilitate the additional 
constraints imposed by the regulations that their development process must consider. The key 
lessons learned of this case study ate: 


e A fully integrated toolset is essential to support the R-Scrum method and to ensure “living 
traceability.” 


* It is necessary that the QA department also adapts; the migration from a waterfall process 
to a Scrum process cannot be done without organizational changes. QA must also adapt to a 
“sprint schedule” in order to achieve “continuous compliance.” 


* Additional roles and ceremonies such as the Dev Check and the user documentation role 
are needed to ensure that any code that is checked in is compliant and propetly documented. 


The sprint-based approach allows QUMAS to always be able to demonstrate the latest version to 
potential customers. The marketing demonstration material is always up to date. This has greatly 
improved QUMAS’ sales opportunities. Based on product demonstrations, several customers 
have pre-ordered new products, even when they were still under development. This by itself is 
noteworthy, and is untypical of in regulated domains. 


The "scaling" of QUMAS' development process has also had a significant impact on the orga- 
nizational and the product domains. QUMAS’ story is therefore representative of the "scaling 
software" phenomenon that this book focuses on. 
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Even if development cost reduction is the most common reason for choosing Outsourcing ог 
Offshoring as a software development strategy, there are many other reasons why companies 


embark on such an endeavor. A bit of clarity over the terms will shed light on what these other 
benefits might be: 


Offshoring means that we relocate all or part of our development to another 
country. We are still doing the development; we're just doing it abroad. 


Putting the low-cost aspect aside, managing workload peaks is a good reason to choose out- 
sourcing, as it is costly and risky to build up and maintain internal overcapacity. Further, to 
balance our investments and risks, it also makes sense to have our own developers working on 
the most important areas and letting a third party take care of less critical development. Another 
benefit that outsourcing brings is agility in scaling development capabilities (both increasing and 
reducing) and therefore ability to faster react to market and business fluctuations. 
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The reasons for choosing offshoring are similar as those for outsourcing. Another good reason 
is the continuous character of an offshoring relationship, with permanent cost reductions and 
without the hassle of contract negotiations with vendors. Moreover, it enables organic knowl- 
edge transfer, growth and “follow-the-sun development." 


Many companies choose near-offshoring where time zone differences are minimal and travel 
time is short between locations. Other companies decide to offshore to regions very far and with 
time-zone differences of six hours or more. 


It's really a matter of how far we want to take it. It's generally more difficult the longer we get 
and the more we detach. But it's not impossible. So, bear with us while we outline a strategy that 
can get you where you want. 


The unforeseen costs 
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Over the years, the trend in outsourcing has gradually shifted focus from reducing costs to factors 
such as availability of qualified personnel, ability to ramp resources, and access to an international 
market. Focusing solely on cost reduction has turned out to be contra-productive. | 


But still, it's ever so common that an outsourcing project starts with a clear drive to cut costs, only 
to turn around halfway moving into firefighting mode. If not well prepared and managed, a proj- 
ect can become mote expensive than when the outsourced task was done internally. And worse, 
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quality issues may negatively impact customer satisfaction and drive the sales down the drain. 


So, we need to get aware of what the real costs ate. Too often, the cost and investment calcula- 
tion are based on a price per person-hour comparison, which hardly give the full picture of the 
total cost. 
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We can expect additional costs due to: 
* Time and effort to transfer knowledge and projects to a third party. 
* Initial quality and security concerns. 


* Delays and long lead times due to communication issues, 
cultural differences and geographical distances. 


\ 

* 

1 * Lack of competence and training -- the supplier may not have the same competence and 
# the ability to achieve the same velocity in development and thus compensates by adding 
mote resources than needed internally. 


This might come without saying, but better safe than sorry: we should expect the running costs 
for managing the outsourcing partner, requirements and deliveries to be higher compared to if 
we had continued running the project internally. 


Staying in control over the costs, or investments which they rather are, will help us not making 
hasty decisions when taking on the real challenges. 
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We're only human 


There will be challenges. Certainly, there are matters we can't predict and matters that are totally 
out of our control. But many problems that arise in an outsourcing or offshoring project can be 


traced down to human nature. It's due to how we communicate, how we motivate and are mo- 
tivated, and make everybody believe in the project (ot not), how we make the journey inclusive, 
and a million other things. We have to deal with them and take these issues seriously. 


On our home site, employees will worry about their jobs, even be annoyed over the idea of 
having to train and transfer their knowledge and work to those that replace them. They will make 
assumptions, rightly or not, leading to an inner resistance to cooperate. Another challenge is the 
need to change roles, routines and processes for the staff remaining at the home site. It's not 
unusual that completely new skills and competences are required, to support an efficient global 
delivery set-up. 


At an external site in for instance India or China, we should expect it's a challenge to attract and 
recruit highly skilled engineers. Most outsourcing partners have great difficulties in retaining 
their staff, resulting in a very high employee turnover. The competition between global engi- 
neering companies that dip in the same pool of skilled workers is fierce. Indeed, there are more 
skilled engineers available than ever on the market, it's just very difficult to hire the best. There 
are indeed lots of engineers with knowledge in modern, standard based technologies. But if our 
system is built on old technologies or requires specific knowledge, they get fewer. This has been 
analyzed thoroughly in this and other studies. 


Due diligence 


Enough about difficulties, let's get down to business. To succeed with 
a mission such as this, we need to analyze and prioritize the following 
parameters: 


Given the costs, distractions, investment of management time and other 
hurdles that will come when getting into outsourcing or offshoring, the 
importance of the due diligence can't be emphasized enough. 


Our strategy 


Once having the due diligence done, were ready 
to outline our outsourcing or offshoring strategy: 


Why do we want to outsource, what are our goals? 
Is the outcome measurable? 


It is very critical to set clear goals and expectations because it shapes everything that follows 
from this point. Without clear goals, we can foresee unfulfilled expectations and uncertainty 
about the outcome of the entire operation. How would we know if we have succeeded? So, de- 


pending on what we want to achieve, what our business drivers are, we could for instance elabo- 
rate with the following targets: 


1. Outsourcing ratio (e.g. 80% of our staff are outsourced and 20% of our staff are in-house) 


2. Cost-saving (e.g. we cut 50% from the current cost) 


3. Market presence (e.g. 10% of the market share in a partner’s country or region). 


What do we want to outsource? 


We need to make a make-versus-buy analysis to determine what's possible to outsource and 
what's not. For instance, complex parts that aren't easily decoupled or used by several other 
projects won't likely be easy to outsource. On the other hand, we might actually want to out- 
soutce a part even if it would be cheaper to develop it ourselves. This would for instance be the 
case if we want to allocate our own resources to more critical activities or if we want to build 
up and maintain capacity for peaks in our wotkload. It all depends on our goals. 


Who can we outsource to? 


In addition to cost, we need to analyze the third party supplier’s competence and maturity, 
development method and delivery model, their financial, legal and security status. We need to 
understand the political situation, and geographical and cultural contexts. If our development 
team will be tied up in ongoing projects and our deadline is tight, we could consider bringing in 
consultancy help. Having clear goals 15 key to be able to objectively select a partner. 


It is critical to stay on top of things and be prepared when the transformation doesn't run as Pros оби 
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smooth as anticipated. The goals are the cornerstones in the measurements and the quality KEN 2 

assurance we need to put in place. Both direct and indirect costs need to be taken into account. on, 


Proactive decisions need to be made at the first sign of discrepancies between plan and reality. 
To succeed in this transformation, we need to be agile and flexible. 


How can we organize ourselves? «lt 
| zatIOnal 
Which new roles will be needed to manage the supplier and their deliverables? While setting up — "e i 


an organization isn't that complicated, transferring necessary product and process knowledge managing 
requires substantial effort and time. Not only do we have to make several trips to the supplier's 区 | 
location, staff from both sites will have to meet face to face, not only to get to know one anoth- ; 
ег, but more importantly to better understand the tasks and challenges they face. It is particularly 
important to introduce incentives for the employees at the outsourcing site in order to minimize 
staff turnover. 
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Get inspired 


This scenario has been based on case studies of different companies that have made this 
journey, to scale with Offshoring or Outsourcing. Learn from their experiences, what they 
gained and what they had to overcome. 


Efficient communication in a global delivery model 
Since this scenario is about the glam of succeeding, and not the gloom of struggling, do 
pay attention to the case study of Tieto. 


Outsourcing Strategy at Sony Mobile 

Read about the smartphone manufacturer, which journey started like many others at the 
time, a bit on a bumpy road. Eventually, they scaled into an organization that was able to 
identify parts that are best suited for outsourcing, to continuously introduce and manage 
outsoutced development projects along with their internal development. 


Not so shore anymore 

This company had an equally bumpy experience when they decided to outsource a system 
that was not particular well suited for the purpose. It didn't go well, but there are still many 
lessons to learn from their case. 


Play it again, Sam, backwards 

Another story to learn from is the rise and fall of Sony Ericsson's PlayNow service. It's an 
excellent example of when bringing development back and run it in-house makes sense. 
They should not have outsourced in the first place. 
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This case study features Tieto, one of the largest IT suppliers in the Nordic countries. As Tieto 
operates in many different locations and with different suppliers, which is why they seek ways for 
efficient communication in a global delivery model. The main driver for offshoring was to reduce 


zn 
Ci 


costs and release personnel for design of the next generation of systems, and at the same time to 
maintain high system availability and service levels. 


The system we focused on has been in operation for over 20 years and is classified as very 
complex with a large number of integrations, databases and functional modules. The system is 
business critical and used in the daily work by approximately 3,500 users. 


To reach a more cost efficient set-up, a major part of the delivery was transferred to a Tieto 
offshore site in Pune, India in 2010. The goal was to reach an offshore ratio of 80% and to keep 
a team with strategic architectural competence in Sweden. 
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The case study was performed five years after the transformation and conducted through several 
interviews with persons involved both before and during the transformation. As the level of the 
offshored activities increased, also the need for project communication and knowledge transfer 
increased. These two factors were later identified as being the key success factors in this opera- 
tion. 


The focus of the case study has for that reason been the importance 
of good communication and knowledge transfer in terms of: 


Competence 

Processes 

Organization 

Requirement handling 
Motivation and engagement 


How further improvements can be made 


The first step in the transformation was to appoint and hire resources in India and send them to 
Sweden for an 18 weeks training program. Next, senior architects from Sweden were sent to In- 
dia for 6 months to build up the competence level of staff of the Indian team. To assist training, 
specifically designed online courses were offered which was an efficient approach. The Indian 
team gradually increased their system knowledge and could take over responsibility for more 
complex tasks already during the transformation period. The regular visits have continued after 
the transformation, in both directions. 


The goal was to establish “one team" distributed over the two sites. Instead of creating a pro- 
cess where each site was responsible for different phases and deliverables, a single team was built 
based on the roles that were needed. The purpose was to bridge between the sites and get an 
efficient communication and knowledge transfer within the team. 


Observations 


Ad-hoc peer-to-peer communication proved to be very efficient in the previous, 
single site organization. Splitting the team оуег two locations resulted in a more 
complex communication structure between engineers from different cultures 
and locations. The team now needed communication solutions such as chat, 
voice and video conferencing. 


The complexity of the system functionality was also problematic. It took longer 
for the offsite part of the team to learn and understand the solution functional- 
ity than the technical solution. The implementation techniques were often quite 
generic. Most difficult to learn was however the customer-specific requirements 
and processes and the various difficult legal constraints. 


Both the Swedish and Indian teams were exposed to new cultures. There are 
significant differences in the way of working, communicating and collaborating. 
The Swedes were surptised about the extensive hierarchical approach to respon- 
sibilities and roles that were common practice in India. This allowed the Indians 
to create an escalation hierarchy that significantly saved time among the Swedish 
architects. 


Another significant cultural difference was high personnel turnover in the 
Indian team. To switch employer is common and a cultural norm in India. This 
turnover requires additional training efforts and jeopardizes successful and sus- 
tainable knowledge transfer. 


The case study team also noted that communication efficiency appeared to be 
much higher after visits between the two sites. In addition, a business trip to 
Sweden was regarded as a very attractive goal in itself and highly motivating for 
the Indian team. 
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Recommendation оп how to succeed 


Make a thorough analysis of the system before selecting competence needs and communication 


strategies. It is more challenging to get an effective offshore for complex systems, so focus on 


functional complexity rather than technical solutions. 


Decide upon a competence strategy early in the offshoring phase. Take this into account when 


staff reduction starts at the local site. It's important to secure personnel for future roles available 
in later phases of offshoring. 


Make a visible step-by-step knowledge transfer process. Tailor training programs to areas of 


expertise and let team members mature over time, area-by-area. Repeat steps рег area: 


D 
2) 
3) 
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Self-study using existing training material (docs and videos) 
Supervised trial operative work 
On-site training with architects 


Unsupervised operative work 


Do not underestimate the difficulty to achieve good awareness in the project, to ensure that all 


team members know what is going on. 


Make an analysis of which recurring meetings that are needed and decide on frequency, 
participants, purpose and scope. 


Decide on communication channels to use and establish good conducts. 


Reduce the amount of redundant communication. Rules and processes for how to commu- 
nicate can solve this problem. Be careful, however, as it also creates latency in communica- 
tion and reduced awareness between sites. Documentation solutions like the wiki will also 
help reduce redundant questions. 


Create processes to continuously secure the quality of the documentation. Old information 
must be removed and relevant information must be searchable and readable. 
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Software has transformed the mobile phone industry. Whereas the first mobile phones contained 
a minimal amount of software, today mobile phones contain more powerful processors than 
those used to put man on the moon. This allows modern phones to do much more than just 
making phone calls, offering many more advanced features. To develop software that makes this 
possible, all major players in this industry have outsourced some of their software development 
— and Sony Mobile is no exception. For Sony Mobile, the main driver was to reduce development 
costs, sustaining growth, and to mitigate difficulties in finding well trained developers. 


All these reasons are very common throughout the software industry. Unfortunately, not many 
companies perform a thorough analysis to evaluate whether cost savings are realistic and achiev- 
able. Sony Mobile didn't stick out here either. Too often, companies embark on outsourcing 
journeys solely to reduce costs based only оп a simplistic comparison of the hourly wages of 
developers. This, however, leads to a completely wrong conclusion when other factors are not in- 
cluded in such calculations. When starting on an outsourcing journey, companies need to spend 
considerable efforts and expenses on knowledge transfer activities, onboarding, and companies 
must also anticipate various barriers that might emerge due to more complicated communication 
that is now hindered by time zones and geographical distance. 


Outsourcing partners — the supplier that will do the customer's work — often don't possess the 
same level of knowledge and experience as the customer company, and often this lack of knowl- 
edge is compensated by adding more people to a the project, all of whom take considerable time 
to build up domain knowledge. This is the first way in which the total cost might end up higher 
than anticipated — perhaps more than if the software were developed in-house. Building up do- 
main knowledge takes considerable time. Moreovet, this is effectively an investment in the out- 
sourcing supplier, and not the customer’s own development staff. For certain outsourced tasks 
that involves standardized (non-differentiating) technology, this may be an appropriate strategy, 
and may pay off when a company is building a long-term relationship with a supplier. 


Another lesson learned by Sony Mobile is to evaluate carefully what should be outsourced. Sony 
Mobile has extensive experience with outsourcing, and this has led to the development of а 
global software outsourcing strategy. They also introduced a shared outsourcing forum for their 
global development centers, which had been struggling with different outsourcing projects for 
years. The global outsourcing strategy defined two major activities. 
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The first activity was to secure a global alignment of introducing outsourcing activities and 
outsourcing partners. Projects, partners and all tasks, risks and issues involved in an outsourcing 
project should be managed systematically and equally. This way, it’s possible to achieve synergies 
and identify best practices—figuring out what works and what doesn't. Security and access rights 
management are two key areas where it is very important to use common best practices, because 
those are critical to Sony Mobile's products. 


Furthermore, Sony Mobile created a common reference process framework for analyzing, 
prepating and executing outsourcing projects, which defines roles and processes for supporting 
outsourcing projects in organization. An outsourcing business manager supports projects in the 
preparation and execution phases of outsourcing projects. The reference framework also in- 
cludes a milestone process for approval and execution of each outsourcing projects, which helps 
to keep track of the stages of the various outsourcing projects within the company. 
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The second activity was to create a decision framework to help business units analyze and select 
suitable components to outsource. Using a tool support, business units can evaluate components 
based on a set of three key parameters. 


The first parameter refers to current capabilities, which refers to competence and amount of 
resoutces. What is the current capability for a given component? Is there a lack of competence 
to implement or maintain the component? Are resources wasted on components that can easily 
be acquired from a third party supplier? 


А second parameter is dependencies, including technical and project dependencies. Techni- 
cal dependencies indicate the extent to which a component is coupled to other modules in the 
system. Project dependencies indicate the level of usage (or reuse) of a given component by 
other projects. If a component plays a key role in many systems, this means it is important to an 
otganization as a whole, and such components should not be outsourced. 


The third parameter is concerned about long term control and competence. This is an indi- 
cator of whether or not it is important to be able to control a given component's roadmap and 
future evolution. When outsourcing (or opensourcing) a component, a certain level of control is 
lost. Components that represent key assets (or crown jewels) of a company, Sony Mobile have 
found it is best to retain development in-house. 


If, on the other hand, components are ‘commodity assets, a company will get very little differen- 
tiating value from such components. In such cases, it may be a suitable candidate to outsource. 
Typically, excellent candidates for outsourcing are software assets that are in the maintenance 
phase or better still, in a dead-end state, where no or limited reuse is to be expected. 
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This is the story of a business unit in a large multinational organization that decided to out- 
source all development and maintenance of one of their systems. The system was a large prod- 
uct lifecycle management system, which was of critical importance to support the organization 
in its functioning. The system's architecture was typical for this type of systems, and the system 
itself was a configured commercial system that was tailored to the organization's needs. Further- 
more, the system architecture was extensible by including custom developed modules. 


In the years btiot to the decision to outsource further development and maintenance, the orga- 
nization had benefited from considerable economic growth. However, more recently the orga- 
nization suffered from an economic downturn, which led management to establish cost saving 
strategies. At the same time, the organization had moved away from a traditional waterfall de- 
velopment process to agile approaches, but still retaining the waterfall’s model focus on defining 
functional specifications — the resulting process was therefore a hybrid one. The development 
organization was still divided in maintenance and development; solution managers were respon- 
sible for the contact with the organization by using the system and develop functional specifica- 
tions with architects and developers. 


In order to cut costs, the organization decided to outsource all development activities. In addi- 
tion to the cost-saving driver, another driver was to become more flexible in spending resources 
on new functionality. The company chose an existing outsourcing supplier that was already used 
for other large systems within the organization. The organization's requirements on cost savings 
resulted in a decision of the outsourcing partner to offshore the entire development to another 
otganization in India. 


The solution manager and the architecture knowledge were retained in the original organization, 
while development was moved out. The outsourced part consisted of about ten developers and 
ten testers. It was clear that a process based on specifications was needed, which meant that the 
previous agile transformation was abandoned, and a waterfall model was adopted instead. An 
implication of this was that the on-site roles became less interesting from a technological point 
of view, which resulted in the architects leaving the project. This in turn led to a reduction of 
skilled and experienced staff that was available which was very important for the requirements 
and design phase. 
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At the outsourcing organization there were developers as in the original organization, but also 
team leaders responsible for leading the work and keeping the contact with the original organiza- 
tion. Turn-around times for development became longer and it became much more difficult than 
anticipated to find more staff at the outsourcing organization when more development needed 
to be carried out. All the customizations became roadblocks. These forced the developers to 
undergo a large amount of training before they could be productive. But, despite all the training, 
they also misunderstood the specifications, resulting in a large number of problems at the first 
major release. 


The initial phase was characterized by long lead times, a large number of misunderstandings and 
low flexibility of ramping up/down the development force when this was needed. They focused 
too much on the formal process instead of having a common view of the development and the 
system was simply too customized. 


After the initial outsourcing phase, efforts were made to improve the understanding of the 
development from both sides of the organization. Representatives from the outsourcing orga- 
nization came to visit the original organization. The original organization started also to visit 
the outsourcing organization more frequently. This resulted in both better understanding of the 
development and in a more personal commitment to the system and the original organization at 
the outsourcing organization. However, the architecture was still too customized. 


A number of recommendations can been made. Creating a common social group for developers 
eatly in the change process would probably have worked better than the starting off with a for- 
mal process based on specifications and hand-overs. It would probably also have worked better 
if the system was less customized, which would have made it possible to find the right compe- 
tence already from the beginning at the outsourcing organization. The developers at the out- 
sourcing site could probably have been involved earlier to reduce mistakes and to gain a better 
understanding about the system and why it was needed. 


The organization decided later to take home the development and conduct it at another business 
unit inside the company. The driver for this was also this time to save costs, but which this time 
was possible as the business unit that will do the development had about the same cost of de- 
velopers as the outsourcing organization. With the same cost structure, but with a development 
otganization closer to the users, we simply get a more efficient development process. 
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PlayNow was Sony Ericsson's download service for media such as music, games, ringtones, 
wallpapers and themes. They used to have the bigger part of the PlayNow team outsourced. The 
development was taken care of by the outsourcing partner and Sony Ericsson took care of the 
project and product management internally. The outsourcing partner actually desired to have the 
project and product managers at their site to drive the software developers more efficiently, but 
this never happened. So the set up was very top heavy. Communication could only go between a 
point-of-contact at each company, causing a lot of time lost. Evety three months the outsourc- 
ing partner delivered a version of the software delivery. This led to a very slow feedback loop. It 
was difficult to know if what had been delivered also was what had been developed. 


Due to cost saving directives, management decided to bring back the software, to develop it in- 
house. This proved to be a more efficient way to work. The cost saving was approximately 75% 
even though cost per head-count was increased. This was mainly thanks to reduction of over- 
head and that they started to work in an agile way with weekly deliveries. 


What we can see from the Sony Ericsson case is that it is not always cheaper to outsource. 
Ovethead, communication and innovation wete factors that certainly added extra cost to their 
outsourcing activity. This is not an isolated case, several other companies suffers from the very 
same problems. A global trend is that the outsourcing market is shrinking. The largest outsourc- 
ing deals in the world are far less valuable today than they were ten years ago, according to IDC 
in the Wall Street Journal. 


To decrease costs is one of the most common reasons to outsource, but outsourcing is not al- 
ways the least costly solution. As in this case, the overhead cost of outsourcing grows that much 
that it is а lot cheaper to bring home the software development. By having the software devel- 
opment in-house it's easier to keep the project in control and to know what is developed and 
why. Those aspects are much harder to manage when all development takes place outside of the 
company walls. Another reason that causes added costs 15 the growing overhead in the outsourc- 
ing organization. Usually only software development costs are included in the cost calculations. 
But, the outsourcing partner also needs to have project managers, architects, system designers 
and line managets. 
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"What to do" 
is about finding the require- 
ments from the customers and to 
communicate them to the software 
developers. 


"How, when and where to do it" 
is about the software develop- 
ment methodology, how we take 
on roles and responsibilities and 
split the organization into a 
sensible structure. Its about 
staying in control regarding 
your source code. Which revision 
should we work on? Which part 
of the software have certain 
part of the functionality? 
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The first things 
are about the very basic needs. 


We need for instance to know what 

to do and how, when and where to 

do it. We also need to check the 
quality of it. 


‘Check the quality of it 
is simply to follow up on 
the planning and the coding 
(by defining and conducting tests). 


Basic principles and concepts for achieving quality, 


Emanuel R. Baker, Mattew J. Fisher, 2007 


This might not come as a surprise, but in case our organization has been growing from just 
about nothing to employ some twenty developers or mote, it's likely we have problems with 
insufficient quality and increasing maintenance costs. We have probably problems with visibility 
when following up on projects and it's likely difficult to make bug corrections without causing 
new bugs. 
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One of the reasons why we have these problems is probably that our organization has outgrown 
out current way of working. Redefining the way of working to match the current size of our 
otganization will in general lead to increased quality, productivity and efficiency of the business. 
It will in particular make the projects more predictable. 


It's hardly a surprise that growing organizations get problems. To do a good job, basically de- 
velopers need to know “what to do" and “how, when and where to do it". As easy as one, two 
three, one might think. As a matter of fact, it gets more and more difficult to spread information 
as the organization grows. What isn't a problem to communicate between very few developers, 
simply is more complicated in a larger team. It isn't rocket science. We recognize this from all 
sotts of contexts, not just business. Yet most software projects fail in their communication. Only 
a software organization in possession of these basic capabilities can be scaled to meet the de- 
mands of today; if not with ease, at least without the chaos it would cause to not have them. 


| PEN | Developers know 
Requirements — c x und stand, 


| are unclear — What to 
| | L implement — 


To state the obvious, our engineers need to know what to do and how to test what they have 
done. The requirements need to be communicated in a way that they understand. While there are 
many ways to manage requirements and every way comes with its pros and cons, most important 
is that we do it. 


Growing the software labor effort from one ог two developers to more than 15 to 30 develop- 
ers puts great demands on both the software process and the software architecture. While two 
developers could handle requirements, configuration management, quality assurance, project 
planning and follow up in an informal way, the larger team simply runs into serious communica- 
tion problems. 


All engineers need to know their roles and responsibilities. The organizational structure must fa- 
cilitate effective communication in all directions, not just vertically. The optimal structure closely 
follows the ways people work, weather they work in projects or in a product line. Agile devel- 
opment methodology, which nowadays is the de-facto way of wotking, promotes for instance 
self-organized teams that in its most extreme implementation can be seen as companies in the 
company. It's safe to say that we should avoid old school hierarchies that merely organize people 
on what they do. 
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About those ever-late projects of ours, they need to be dealt with. It's not that our current 
project managers aren't doing their job; it's just that they have to change direction every now and 
then. The ways to plan have to be adapted to the reality, where plans are revised continuously. 
It's wise, though, to not overdo the planning and instead try to capture the few next weeks in 
detail. In Agile development methodologies, already mentioned, all planning is made in two- 
week chunks. Trying to grasp a much longer period of time into a plan has simply shown to be 
doomed to fail. 


In what state is out software architecture and how do we manage it? The software has to serve 
its purpose, to fulfill the function for which it was created. It must also be firm in terms of 
structural integrity and durability. If optimally designed we should be able to: 


* Make changes in one part of the system without negatively affecting other parts 
* Distribute work in the system between different departments 


* Reuse software components from one part of the software system in another 
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It's key to design the system as a set of clear-cut parts embodying well-defined boundaries. Soft- 
ware architecture is, simply put, how these parts are structured and how they relate and commu- 
nicate with one another. The architecture starts with its documentation, a blueprint that governs 
how to design parts in order to facilitate development of the software system. And, as with ways 
of working has the organization to tightly follow the architecture. 


Finally, we have the testing. Is this activity considered the necessary evil that continuously gets 
down prioritized when the project slips in time? If so, we should really be cleverer. To monitor 
and evaluate how the organization is doing quality-wise pays of as soon as the heat is turned on 
and the business gets into full production mode. When everyone involved runs as fast as they 
can, occasionally even making short cuts to get in time, there's simply no room for thinking 
about what can be improved. The test activity 15 really our only mean to identify bottlenecks and 
to optimize processes and tools. 
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Optimally, to ensure we're going in the right direction, both the plan and the software ought to 
be followed up on. This shouldn't be done at the end of the project but frequently, tightly cou- 
pled with the iterations in which development takes place. We would want to keep the feedback 
loop as short as possible. All Agile development methods have this built-in to the method. At 
the end of the iteration, an automatic test script would test the software and a retrospect would 
evaluate if we work in a good way ог if a change of direction is needed. 
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Being one of the engineering disciplines mostly written about, you shouldn't have to go far 
to find in-depth success stories and lessons learned from diverse efforts in straitening up 
software organizations and architectures. The following pages summarize the real-life case 
studies that were conducted to define this scenario. 


Robotic growing pains 
Read about Husqvarna's experience when they added Internet of Things to some of their 
lawn and garden products. 


Softhouse reflects on architecture changes 
Learn about the effects of architectural changes in Android development. 


From mobile to platform 
The platform concept builds on components that easily can be changed or configured. This 
enables new products and offerings to be created quickly, without having to redo a lot. 


One more thing 


When scaling through First things first a development 
method has to be chosen. As we have hinted throughout 
this scenario, it is strongly recommended to work in an 
agile way. Find canvases for Agile development in the 
chapters Pump up the volume, Deliver 24/7 and Agile 
and disciplined. 


Husqvarna Robotics had grown from a small team of 3 software engineers to over 30 software 
engineets in a very short time. They understood they needed to improve their quality and project 
predictability because of the problems they had with their software development. 
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Robotics had started to get problems with late deliveries, bug corrections very often led to new 
more serious problems, and new bugs reports from the market disturbed the software team in 
their work to develop new functionality, this led to delayed software projects and releases. Project 
managers were not confident that the software team could deliver according to the plan. Archi- 
tecture improvements were pushed in the future, due to lack of time. The testers did not have 
time to test everything in a release, which led to even more bugs being reported from the market. 


Project management did not know which requirements being implemented at the moment. 
There was little visibility of the progress in the software team. All software was delivered late to 
the main branch. At that time a major part of functionality did not work, so what was working 
or not wouldn’t be discovered until very close to the release of the product. 


Product management did not have confidence in that the software organization was delivering 
new functionality efficiently. 
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During fall 2014 а series of general seminars in software engineering was conducted in the entire 
R&D organization. Robotics understood it would be good to get external help to do an analysis 
of the current situation. A kick-off of the improvement project at Robotics was held in Septem- 
ber 2014. A series of interviews was held and a report of the situation and improvement pro- 
posals was presented in January 2015. 


Suggestions of improvements were made for the areas such as requirement handling, project 
planning, project tracking, software quality assurance and configuration management. It was also 
said that the software architecture needed to be restructured. 


А new meeting was held to agree on which changes to prioritize. The software organization, 
project management and product management were all involved in this decision. 


The most important suggestions of improvements from the audit were prioritized to be imple- 
mented during the first half of 2015. 


In April 2016 the software organization had a completely new situation. Instead of the negative 
atmosphere that characterized 2014, a more positive attitude characterized the organization. The 
software team was positive to the new ways of working and they believed they were working in a 
good way. 


By the end of 2016 the initial team of three had left the company. They did not find their place 
in the larger organization. Even though this was a large competence loss, the organization was 
now better prepared for situations like this. The new ways of working and the new documented 
architecture made the organization less dependent on a few уегу competent champions. 


Husqvarna has in this project gone through a very common growth problem. The exact same 
problems were found in several different Ericsson departments in the early nineties and have 
been found in several other companies since then. 
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А typical situation in software development is that a product is developed as a prototype ог as а 
first version but in a rather small scale, and then the product and the number of included func- 
tions grow. One problem with this is that the software architecture might not be suited for what 
it is used for, thus resulting in added functionality that causes unpredictable software faults. It 
gets necessary to improve the architecture through refactoring. This happened to Softhouse. 


There wete three main reasons for Softhouse to make a change in the software architecture: 


* The amount of code and functionality a new team member needed 
to understand was too latge. 


* There was a negative trend of quality issues like old bugs being 
re-introduced and too many errors found late in testing. 


* The software system would be significantly extended in the 
near future and be used in new ways. 
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Starting as a small prototype, they created a client system to provide their customers with data 
from their internal information systems. As the usage of the client system grew, the product it- 
self and the number of functions increased rapidly. A problem was for instance that any changes 
in the product affected many parts of it, which resulted in unpredicted faults. 


The system was built with focus on reuse, i.e. when new functionality was added, existing class- 
es were reused as much as possible. This focus lead to an architecture with many dependencies 


resulting in a monolithic system. This was identified as the reason behind the many quality issues. 
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To make the design less fragile, the architecture was divided into modules. Each module imple- 
mented one specific function provided to the user. Functional decoupling allowed the developers 
to make corrections or updates of existing functions more efficiently and with higher quality. It 
also allowed for parallel updates of different functions at the same time. It also allowed for intro- 
duction of new functionality independent of the existing ones. 


The architecture guidelines were changed to stress on the use of independent modules and how 
to manage them individually. Drawbacks of architectures like this are less reuse and more double 
maintenance of similar code in different modules. However, changes can mostly be limited to 
one module and therefore fulfill the maintainability requirements. 


The project followed an agile approach similar to Scrum with collective code ownership where 
the developers assign the tasks to themselves. The new process allows developers to avoid 
change requests in modules they haven't knowledge in. From an organizational perspective, the 
new architecture makes it easier to scale. New developers that join the project can start work on 
one function in one module and learn the system function-by-function. The new software archi- 
tecture is now used in full effect. 


New markets New business models 
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\ SY From mobile to platform 


To move towards a platform development strategy, where the same software is used in many 
products, is quite natural and a common strategy in many companies. After the first product has 
been successfully released, the company now looks for ways to grow the business and to reuse 

the investments already being made. 


The platform concept builds on modularized, stable and reusable components that easily can be 
changed or configured. This enables new products and offerings to be created quickly, without 
having to redo a lot. Howevet, the strategy and its implementation is always an act of balance 
between reuse and product focus. 


When Sony Ericsson started to take off after the success with their first mobile phones, all 
their activities took place in product projects. There were two similar product development 
otganizations with redundant development competence as a way to develop more than one 
product at a time. After the first products had been released there was a need to increase the 
business and offering even mote. It was of coutse not possible to scale up the development 
capacity linear to the number of products in the portfolio. So a platform concept was intro- 


duced. 


The old software architecture was heavily impacted by the platform concept. Modularizing and 
layering of the architecture together with a configuration and customization framework were 
key concepts and patterns in order to create the platform concept. It was essential to identify 
common functionality and things that needed to be customized, in creating the configuration 
and customization framework. 


This made it possible to maintain and reuse the majority of the software and functionality and 
thus only work with configurations and some product and customer specific development. This 
also led to that the number of product variants grew dramatically. 


This in turn had an impact on both the processes and the organization. The soft- 
ware configuration department grew and became the heart and engine of the develop- 
ment. А special software release management organization and process were established 
to cope with the large number of variants. How to test and verify in a cost efficient way be- 


A 


came the billion-dollar question, as they couldn't multiply the test activities in a lineat way. 
They had to find ways to also reuse test and verification in a smart way. 


Sony Ericsson was successful in this journey since they were able to release more and more 
products without having to increase the work force in a corresponding way. The time-to-market 
and cost per product reduced significantly. 


— So did they continue to improve and become better and better? 
The answer is no. 


As the platform concept grew stronger and stronger the focus on the product itself and its 
offering became weaker. The platform projects and its organization grew bigger and bigger 
and tried to include more and more products in its releases. Together with а waterfall approach 
this led to that the platform projects became slow and inflexible giants. These tried to please all 
products with all their market and customer needs. This also made the projects lengthy as not 
all products were released at the same time. As a way to cope with all the products and require- 
ments, the platform projects started to claim that all requirements had to be set at least two and 
a half to three years prior to the product releases. This was not possible in the mobile industry 
during mid-2000, as tons of new features and concepts were released every year. 


The organization and process became impossible to maneuver and the product offerings became 
late and were not competitive enough on the very tough mobile phone matket. 


The lesson learned is that a platform concept that is well prepared and balanced with a contin- 
uous product and customer focus can lower time to market and reduce development cost. But 
it's an art of balance, to find the optimum level of abstraction, to what extent it is reasonable to 
reuse system components. 
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Please come in. Weleome to our 
home turf Its time to roll up your 
sleeves and ill the whiteboard. Youll find the 
Post-It notes on the table. Weve already put 
up blue ones. As usual these represent your in- 
ut, what wed like to achieve. Now, go ahead and 
fill the board with orange and yellow ones. Describe 
what changes you think it would take. Wearing 
your glasses, consider the impact on our organ- 
ization, on our ways of working and on our 
offering. Needless to say, before you jot down 
your note, browse through the shelt with 
notes from previous experiences. 
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Defining a transformation journey is an important step in the transformation process. In this 
chapter we'll show how to setup a workshop to identify the steps that an organization can take 
to embark on a software scaling transformation. The proposed solution from the workshop will 
be a concrete list of transitions describing changes in the three key domains that the Scaling 
Management Framework (SMF) defines: product, process, and organization. We'll use a canvas 
throughout the workshop to support this process. 


The workshop in short: 


1. Define the drivers - They should be derived from the company business strategy. 
2. Decide on inabilities and desired abilities that will drive the change. 

3. Identify the current domain characteristics that cause the current inabilities. 

4. Use the compass to find a solution and read relevant scenarios with similar drivers. 
5. Prioritize the transitions and start to implement. 


Setting up the workshop 


Defining a transformation process isn't just simply following a set of steps — it requires thoughtful 
participation and creativity. However, using the canvas to structure the ideas and drive the process 
will make this more efficient and more fun. It also helps in communicating the results to a wider 
audience, varying from other managers to developers. 


Running a successful workshop depends heavily on active participation and brainstorming by all 
participants. It's important to get everybody engaged to encourage innovative and creative con- 
tributions. This can be achieved by actively coaching this process and asking open questions, but 
beware of critical comments and feedback that might discourage participants. Later on in the bto- 
cess, the pros and cons of different strategies are evaluated before decisions are made. We won't 
go into different theories and techniques on how to optimize the workshop phases and group 
dynamics. Instead, we'll focus on the purpose and content of each phase, and how we use the SMF 
and the canvas to support the process. 


To get started, you'll need to have access to all decision makers in the organization. Remember 
to cover input from both management who understand the drivers, and from specialists from all 
three SMF domains: product, process, and organization. As illustrated in the introduction, it's pos- 
sible to divide the work into two workshops without having all persons on site at the same time. 
However, when possible it is always best to gather all roles and skills in the same room at the same 
time, and let them wotk iteratively together. 


Some practicalities before we start the first workshop: 


Make sure that the room is equipped with a whiteboard and a projector that can display the canvas 
on the whiteboard. Being able to put up post-it notes and connecting them with lines and arrows 
is important. 


Get post-it notes in different colors, preferably in five colors (blue, orange, yellow, green, and red). 
We use colors mostly because we find it easier to put them into context when discussing them 
together, to get a good overview of the situation. Actually, for most post-its, its place in the canvas 
tells what type it 15. The color is mostly redundant, but the visual distinction can help. There is 
one place where it isn't redundant, so you will need at least two colors to distinguish the meaning. 
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Let's start! Why are we here? 


Put the SMF canvas on the whiteboard. Present the goal and the expectations of the workshop 
and explain how the workshop will be performed. 


The goal is to create a list of transitions to be implemented in order to reach a couple of goals 
and abilities. These ate typically identified as drivers based on the company strategy. 


In order to reach this goal there are a couple of sub-targets. Although this is an iterative process, 
it's good to know the purpose and goal of each phase (sub target). 
What is our strategy? - What are the drivers? 


The first step to set the course is to define the drivers for the need to scale. Drivers are the 
reasons why we need and want to scale our software, and are often closely aligned to the compa- 
ny's strategy. Typical drivers are a desire to enter a new market or market segment, or to become 
more innovative. Rapidly expanding organizations can also suffer from growing pains, for exam- 
ple when if the software architecture doesn't scale with the organization, or when well-trained 
staff is hard to find. 


Start with the external drivers 


Most drivers are external, i.e. derived from outside the company. It can be customers, markets, 
or global regulatory requirements that want us to make the changes. To get our brain to start 
formulating these drivers we can ask questions like: 


* What are the market or customer expectations on our organization? 

* What are the management team expectations on our organization? 

* Have any regulatory requirements been changed that we need to cope with? 
* Where is the market heading — What ate our competitors doing? 


Utilize the help from the structure of the "driver groups" and ask what really drives the compa- 


ny to a successful future. Is it the ОРЕХ cost that needs to be lowered or is it rather a complete 
new business model that will outperform our competitors? 


Fill the top area of the canvas with blue post-its, each with a driver. This can be done in many 
ways. For example, we can let the participants do this one by one. We can also do it in small 
groups and ask one person from each group to present and argue why the drivers are important 
to have from an external point of view. It's important that all post-its are discussed and under- 
stood (and maybe even rephrased) by everybody before being put on the canvas. 


When all notes are on the canvas we most likely need to group and reduce them according to a 
prioritization. 


* Group them in new common areas if possible as the number of post-it notes grows. 
* What are the two to three most important items to focus on? 


Put the drivers on the canvas in priority order from left to right. 
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Good things we want to keep 


The drivers primarily capture things we want to change in order to scale. However, at this point 
it can also happen that there are proposals that at first glance seem good but at the later discus- 
sion turn out to have negative impact on already existing (good) drivers. Here we have the possi- 
bility to remember this by creating post-it for a driver we want to keep. Keep these post-it notes 
to the right on the driver's area, to distinguish these as external drivers. 
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Continue with internal drivers 


Most drivers are external, but sometimes we also have internal drivers. These are things the 
customer or market not specifically ask for, but we still want to achieve as we think it is the right 


direction for the future. Ask questions like: 
* What would make us proud? 
* What kind of wotk climate do we want to have? 


* What do we need to be well prepared for the future (which is sometimes not so easy to 
predict — so why not become as prepared as possible)? 


Generate blue post-it notes. Explain, discuss and btiotitize them. Add the most important to the 
left of the external drivers. Post-it notes that are removed due to prioritization can be stored in a 


"parking lot" for later retrieval if needed. 


"+, Desired abilities and current inabilities 


e 
e 
: o Now when we have all the blue post-it notes in place, 
e š Pr a sje == DI 
y^ ә next up is to identify the abilities. Abilities are aspects 
Ы °° of the software development such as cost, performance, 


and quality, which are possible to measure without know- 
ing any details of how the development is made. In the 
workshop the goal is not to create all-covering measure- 
ments of the entire software development, but we will fo- 
cus on abilities we need to have in order to meet the driv- 
ets, the desired abilities. We will also identify the current 
inabilities, the abilities we have today that we need to 
improve in order to get the desired abilities. Start by 
looking at the drivers and formulate measures related 

to them. If the drivers are about customer satisfaction, and product quality, the desired abilities 
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will most likely be about number of issues, customer satisfaction survey results or time to market. 
In a company works with KPIs, hopefully we will find our Drives in these. 


The desired abilities will be the "Definition of done" in the implementation phase, so 
look carefully at them and ask, "Have we succeeded if we reach this?”. 


When the desired abilities are in place continue with the current inabilities. What is it that is not 
good enough — what are out growing pains? Obviously, many of them will be similar to the de- 
sited abilities, like for instance customer support availability: a desired ability is 24/7, but current 
inability is office hours. 


Put up post-its both for the desired abilities and the inabilities and make sure they cover all 
+ Һе drivers. 


* Iterative process 


e . В . . eyes . DIS . В 
IL To identify drivers, desired abilities, and inabilities is an important sub target. It often 
requires an iterative workflow (consider- 
ing the software development as a black 


box) that doesn't finish until we are on com- 1 n 


mon ground with the company's strategy and 


vision. Ми —— 


In many companies, the people that define 
drivers and abilities, and the people that can 
break these down in terms of organization, 


process and product, are not the same. In 
such cases, it's possible to first have a lim- 
ited workshop with management only, to 
decide on drivers and identify abilities, and 


use this outcome as input for a subsequent co — J 


workshop . 
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Explain current abilities with domain capabilities 


Now it's time to open the black box. We need to understand why we have inabilities, we need to 
analyze and describe our current situation as 15. 


Ask challenging questions within all three domains: product, organization, and process. Identify 
the current domain characteristics that potentially are the problems causing the inabilities. Find 
characteristics, that if changed will solve or remove 

the current inabilities. A domain characteristic is sim- 


ply explained as a hallmark for the company's software 
development. Examples of such are “manual test and 
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delivery,” “по routines for source code management" 


and “по process for customer requirements." 


Don't just look for the no-brainers, we might have to 
nest and ask “why” for quite a while to find the root 
cause. Why do we have a manual test? Maybe is it 
because we lack the competence to create automatic 
tests. If so, this is a yellow note in the organization 


domain rather than one in the process domain — or 
both with a line in between depicting the relationship. 


During this phase we really need domain experts, people from the company that know how 
things actually work. What are the actual practices that are used? What does the product archi- 
tecture look like and what affects on the abilities does it have? 


Troubleshooting requires deep knowledge about dependencies - causes and effects. This means 
we also need people with good general knowledge about the domains and the characteristics of 
different solutions. If the knowledge can't be found within the company, bring in external com- 
petence to the workshop. Such people can also assist as moderators and help getting a holistic 
view of the discussion. 


Use the building blocks within the domains to, in a structured way think through how we actual- 
ly work and why. In the organization domain, go through all four blocks (structure, culture and 
leadership, people management, and improvements) to seatch for reasons to the inabilities. Let 
the experts from this domain shortly explain the current characteristics of each building block. 
Discuss if we should add a yellow note. 


Use competence from all three domains to really find the reasons to the inabilities, what prevents 
us from reaching the desired abilities. Put up yellow notes and draw arrows between them to 
show dependencies. 


Don't stop until all inabilities are explained by at least one domain characteristic. For non-obvi- 
ous relations, draw an arrow in the canvas, from the yellow domain characteristic to the orange 


inability. 


We might identify existing 
characteristics Were about to 
remove or change, but during 
the discussion realize We ought 
to keep these. Leave these in 


the canvas and mark them with 
“Keep”, to remember they are 
also part of the desired solution. 
These wont have any arrows to 
current inabilities. 
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Find a solution 


Now the creative part starts. We need to decide on what changes to make in order to improve 
and meet the abilities and drivers. In other words, we need to define the transitions the company 
needs to do. 


The goal is to have yellow post-its in the 
three software domains fulfilling the de- 
sired abilities. Each yellow note in the as-is 
domain should have a transition explain- 
ing how it is transformed into the desired 
solution. When not obvious, draw arrows 
depicting the transitions. Similarly, all yel- 
low notes in the desired domain should 
have corresponding transitions needed to 
have them implemented. 


In reality, this isn't so easy. Most like- 
ly there will be many alternative transi- 
tions with different pros and cons and no 
obvious “silver bullet" solution. Also, a 
transition in one domain may also affect 
other domains. As an example, to make a 
quite obvious change to a process might 
also call for changes to the organization, 
e.g. new skills needed. In these cases, we 
need to add yellow notes also explaining the needed "supportive" desired domain characteristics. 


Make sure to evaluate different transition possibilities. Also make sure that all desired abilities 
have been addtessed befote the final set of transitions is defined. 


248 


1 © : Use the body of knowledge and experiences to be creative 


e. . Although both finding the root causes and searching for the best solution are a very 

creative tasks, it is also here we can use this book to utilize the experience from previous 
situations in other companies. Journeys and travel stories provides us examples and captured 
experience from other companies who have been through similar situations. 


The best way to find relevant scenatios is to look at your drivers. In which one of the five 
main driver groups do you see your drivers. Then, go to the “The compass" part of the 
book to find relevant scenarios to read for your driver group. 


An alternative way of using the book 1$ if you want to know how companies similar to yours 
have done. Browse through the journeys and see if you can find a company relevant for you. 
As evety journey is exemplified with several Travel stories, we encourage you to read the 
entire journey for the selected stories. The canvas for each journey and Travel story gives а 
quick overview in order to determine if a more thorough read is needed. 
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° $ Decision time 
°. a? All sorts of design ideas have been discussed, pros and cons argued, and trade-offs worked out. 
It's time to outline the initial change project. as 


When the characteristics of the future software model have been defined and we know what 
changes we need to make, document the changes. Start with the main transitions and draw ar- 
rows to show how the new domain charactetistics result in the desired abilities. 


As we know we might need additional transitions to create the pre-conditions needed for the 
main transitions, add also these to the canvas and draw arrows to show how they support the 
main characteristics. 


At last, if we need to execute the transitions in any specific order, also add notes or arrows that 
describe the dependencies between the transitions. 


Use the dependencies between the transitions and put together an ordered list of transforma- 
tions. This list can be used throughout the implementation of the change. In the next chapter 
you will see how to succeed with the actual change implementation phase. 
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.. most organizations lack 
all the skills needed to implement 
and optimize business processes ... 


Successtul process management 
requires an agile iterative approach 
to process change. 


Gartner Inc. 
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Specification 


Budget Time plan 


The Scaling Management Framework will help you to identify the transformation journey to 
take. It can also help you in dividing the transformation project into reasonable steps. While un- 
derstanding what to do is crucial, it's not the same thing as knowing how to do it. Every change 
needs success criteria, a project team, a plan and a budget. However, the planning accuracy is not 
saying if your change project will be a success or not. 


А successful implementation requires a lot of wotk from all employees involved. Everyone needs 
to understand why there is a need for change. They have to acknowledge the reason that drives 
the change and understand how it affects the organization and the ways of working, If it isn't 
clear “what's in it for me,” there is a risk that the project will meet resistance from the employees. 


One obvious factor for success is the ownership and the attention from management. High-level 
progress should be communicated from top management and not only from the project lead- 
ers, which should focus on more detailed information sharing. Visibility and transparency in the 
change process is a key aspect to grow trust and motivation among the employees. The manage- 
ment team should also support the project removing any impediments that might arise during 
implementation. 


A change project can be set up similar to an agile project. Using a prioritized change backlog, use 
small iterations and retrospectives to minimize the work in progress and keep the lead-time 
short. The agile change process provides a lot of tools to follow up the results and track the 
progress. All measurements should help to drive the change (or at least not slow them down) and 
serves also to reinforce the motivation. 
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Agile change center 


The Agile change center is a framework for guiding any transformation, based on the same 
principles that guide agile development. Through determined commitment to small, continuous 
and incremental change, the Agile change center may be used to investigate, propose, facilitate, 
execute and deliver any of the change scenarios presented in this book. 


The Agile change center primarily seeks to accelerate the transformation and provide: 
* Organizational alignment around agreed drivers and abilities (KPIs) 
* Management engagement in the transformation 


* Mechanism for continuous and sustainable improvement aided by visibility, feedback and 
reflection 


The center consists basically of two teams, the management and the doers. The management 
team defines drivers and prioritizes and aligns the overall transformation. They set all drivers, 
such as goals based on sales growth or return of investment. They have also identified abilities 
that they want to measure on, critical success factors of the transformation. 
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Management team 


The implementation teams are manned with all necessary competences to roll out the transfor- 
mation. Two important members of such a team is the transformation owner, who represents 
the management team, and the Agile coach, who facilitates the performance, learning and devel- 
opment of the individuals in the team, as well as the team per se. 


The management team meets every 2-4 wecks, to refine the change backlog, prioritize change 
items and to follow up on previous change items. The change backlog contains all actions in the 
transformation. It's basically a list of change Items that is prioritized by the management team. 
А change item can be any opportunity for improvement, in any of the three SMF domains. The 
opportunities can be expressed as impediments of a problem, investigations, proposals ог sug- 
gestions. 


The implementation teams meet every 1—2 weeks, for iteration planning and commitments, to 
review progress and give feedback and to look back at changes that already have taken place. 
АП but the transformation owner meet as well every one or two days to synchronize work, raise 
difficulties and ask for help. 


Transition owner Rollout team Agile coach 
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International License (http:/ /creativecommons.org/licenses/by/4.0/), which permits use, sharing, 
adaptation, distribution and reproduction in any medium or format, as long as you give appropriate 
credit to the original author(s) and the source, provide a link to the Creative Commons license 
and indicate if changes were made. 
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Commons license, unless indicated otherwise in a credit line to the material. If material is not 
included in the chapter’s Creative Commons license and your intended use is not permitted by 
statutory regulation or exceeds the permitted use, you will need to obtain permission directly 
from the copyright holder. 
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Alphabetical list of terms and definitions 


Abilities 


Case study 


Characteristics 


Current organization 


Current process 


Current product 


Abilities can be seen as Key Process Indicators (KPIs) for the 
transformation journey. The KPIs are preferably the ones used in 
the company's Balanced Scorecard. Abilities have to be measur- 
able in order for us to recognize if we're getting any better. The 
whole organization, with its three domains, is considered being a 
black box when we measure such abilities. 


A case study gives real world experience from a company that is 
in the midst of or past their digital transformation. Some compa- 
nies have been successful and some have not. 


The characteristics of an organization is how it looks when we 
open up the black box and see in detail what is happening. The 
cutrent characteristics ate the root cause of the inabilities and 
the desired characteristics ate the reasons to why we achieve the 
desired abilities. 


Defines the root causes of an inability within the organization 
domain. 


Defines the root causes of the inabilities within the process 
domain. 


Defines the root causes of the inabilities within the product 
domain. 


Digital transformation 


Digitalization 


Drivers 


Inabilities 


Organization domain 


Process domain 


The process of radical change, where companies are converting 
from an analog to a digital world. 


The process of converting from analog to digital. Digitalization 
means a shift in focus from products, hardware, and mechanics 
towatds software and services and possibly disruptive business 
models. 


The key priorities a company's management board would look 
for the software organization to address to cope with the digital 
transformation. They can be grouped into five main categories 
of dtivets and equals to the goals of the software organization. 
These drivers are the rationale for why we need to change the 
software organization. 


Inabilities are the abilities that currently hinder us from achieving 
the drivers. The inabilities are mostly visible outside of the orga- 

nization, by other entities within a company ог outside a compa- 

ny such аз by customers. 


The organization domain includes all organization and business 
processes including, but not limited to, how to structure the or- 
ganization, culture and leadership, people management and how 
to drive improvement work. 


The process domain covers all aspects of how a product ог a ser- 
vice is developed and tested. We have chosen to divide this into 
two subcategories: engineering and project management. 
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Product domain 


Scale 


Scenario 


SMF 


SMF canvas 
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The product domain covers the products and services that we 
offer on the market. This domain deals with aspects like the soft- 
ware architecture, how we structure the product or service, the 
infrastructure and our distribution channels. 


Software companies have to scale, which is another way of say- 
ing change with the digital transformation. 


A condensed set of lessons learned extracted from case stud- 
ies with similar drivers. A scenario is lessons learned by several 
companies with hands-on experiences from similar digital trans- 
formation. 


The SMF (Software Management Framework) helps companies 
with one of the key challenges of European Industry: how do 
we transform our organization when software is becoming a 
critical part of our offering and asset? The digital transformation 
that comes can partly be driven by the technological evolution 
and partly by the business. The SMF is distinctive in the sense 
that it explains the transformation in three domains — organi- 
zation, products and processes — in the same model. The SMF 
consist of the map, the compass, the travel brochures, and the 
travel stories. 


А graphical tool for understanding and describing the transitions 
needed for the software organization to carry out a digital trans- 
formation. 


Software organization 


The compass 


The journeys 


The map 


The travel brochure 


The travel story 


Transformation 


Transition 


A software organization can be an IT department and/or a soft- 
ware R&D department. 


The five common drivers are used as the compass in the trans- 
formation journey. They will guide you through the map and 
help you to pin down your own digital transformation journey. 


A database of industrial best practices and tools to support 
enterprises in their digital transformations. The database contains 
travel stories and travel brochures to be used at the digitalization 
journey. 


The SMF canvas is used as the map of the transformation and it 
helps in creating a digitalization strategy. 


А scenario can be seen as a travel brochure for the journey. 
Case studies give the reader the concrete travel stories. 


А process of radical change that orients an organization in a new 
ditection. 


One or more transitions are needed to make the digital transfor- 
mation in a company. A transition is the key activities needed to 
go from the current characteristics to the desired characteristics. 
In the SMF canvas, this is graphically represented as going from 
one or several yellow post-its on the current side to one or sever- 
al yellow post-its on the desired side. 
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Desired abilities 


Desired organization 


Desired process 


Desired product 


Your journey 
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The desired abilities are the desired state that we want to reach 
for our KPls. They are clearly defined and are measurable. They 
will indicate if we have reached our goals with the transforma- 
tion performed ог not. 


Defines the desired charactetistics of the organization domain, 
which enable us to achieve the desired abilities, which turn is the 
end goal for our drivers. 


Defines the desired characteristics of the process domain, which 
enable us to achieve the desired abilities, which turn is the end 
goal for our drivers. 


Defines the desired characteristics of the product domain, which 
enable us to achieve the desired abilities, which turn is the end 
goal for our drivers. 


When a company uses the map, the compass, the travel bro- 
chures and the travel stories to define their own digital transfor- 
mation journey. 


Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 
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adaptation, distribution and reproduction in any medium or format, as long as you give appropriate 
credit to the original author(s) and the source, provide a link to the Creative Commons license 
and indicate if changes were made. 

The images or other third party material in this chapter are included in the chapter’s Creative 
Commons license, unless indicated otherwise in a credit line to the material. If material is not 
included in the chapter’s Creative Commons license and your intended use is not permitted by 
statutory regulation or exceeds the permitted use, you will need to obtain permission directly 
from the copyright holder. 
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